Change request visualization in hierarchical systems

ABSTRACT

Various techniques are disclosed herein for storing and managing master data in hierarchical data systems. Several related concepts, embodiments, and examples are disclosed, including techniques for incremental rationalization in a hierarchical data model, techniques for implementing governance pools in a hierarchical data model, techniques for application materialization in a hierarchical data model, techniques for data intersection mastering in a hierarchical data model, techniques for change request visualization in a hierarchical data model, and techniques for hierarchy preparation in a hierarchical data model.

CROSS-REFERENCE TO RELATED APPLICATIONS

This continuation application claims the benefit and priority of U.S.application Ser. No. 15/648,216, filed Jul. 12, 2017, entitled “CHANGEREQUEST VISUALIZATION IN HIERARCHICAL SYSTEMS”, which claims the benefitand priority under 35 U.S.C. 119(e) of U.S. Provisional Application No.62/396,147, filed Sep. 17, 2016, entitled “MASTER DATA MANAGEMENT INHIERARCHICAL DATA MODELS,” the entire contents of which are incorporatedherein by reference for all purposes.

This application is related to U.S. Pat. No. 7,305,419, entitled“HIERARCHICAL REFERENCE DATA MANAGEMENT SYSTEM AND METHOD,” filed onMar. 25, 2004, and issued on Dec. 4, 2007. This application is alsorelated to U.S. Patent Appl. Publ. No. 2016/0092818, entitled “METHODAND SYSTEM FOR IMPLEMENTING AN ADAPTIVE DATA GOVERNANCE SYSTEM,” filedon Sep. 23, 2015. The entire contents of U.S. Pat. No. 7,305,419, andU.S. Patent Appl. Publ. No. 2016/0092818 are incorporated by referenceherein in their entirety for all purposes.

TECHNICAL FIELD OF THE INVENTION

The present disclosure relates to various techniques (e.g., methods,systems, non-transitory computer-readable storage memory storing aplurality of instructions executable by one or more processors, etc.)for storing and managing master data in hierarchical data systems.

BACKGROUND

Organizations often store various critical data in databases or otherelectronic storage formats. The critical data stored by an organizationmay include data relating to any aspects of the organization, such astransaction data records, technical system data records,business-related data records, and the like. Data that may be used inmultiple different data records may be referred to herein as referencedata. For instance, within a business organization, data identifying aparticular customer, employee, document, product, product line, store,geographic region, computer server, network device, or user terminal,all may be examples of reference data, in that each of these examples ofdata may be referred to in multiple different data records (e.g.,multiple purchase transactions may involving the same customer orproduct, multiple network monitoring records may identify the sameservers or network devices, etc.). Additionally, different types ofreference data may be interrelated in a child-parent relationship,sibling relationship, etc. In such cases, the organization data may bereferred to hierarchical data, and the arrangement of reference data toreflect these relationships may be referred to as a hierarchy.

Moreover, organizations often have multiple different systems forreceiving, storing, analyzing, and outputting data. Such systems may beheterogeneous, so that each system has its own hierarchy or hierarchiesof reference data. Each hierarchy may organize different or overlappingsets of reference data according to different criteria. For example,different pieces of data stored or represented within different systemhierarchies may correspond to the same reference data. For instance, afirst heterogeneous system may store reference data hierarchically basedon the organization's internal structure (e.g., business entity,department, store/office, etc.), while a second heterogeneous system maystore the same or overlapping reference data hierarchically based on thegeography (e.g., continent, country, region, store/office, etc.). Theseheterogeneous systems may have no knowledge of the hierarchies employedby other systems, even if a portion of the reference data overlaps. Insuch cases, the organization may generate and maintain a master set ofreference data to provide a single source of the shared organizationdata.

BRIEF SUMMARY

Certain embodiments of the present disclosure relate generally tostoring and managing master data in hierarchical data systems.

Various techniques (e.g., systems, methods, computer-program productstangibly embodied in a non-transitory machine-readable storage medium,etc.) are described herein for performing incremental rationalization ofhierarchy data. In some embodiments, inputs may be received identifyingtwo or more data dimensions of various applications in a hierarchicaldata system, and a mapping may be generated between the different datadimensions. After the generation of the data dimension mapping, changeswithin the data nodes of the data dimensions may be detected duringexecution sessions of the applications, and in response to the detectedchanges, data indicating the changed data nodes may be provided to thecorresponding applications. Further techniques may relate to theimplementation of governance pools within hierarchical data systems. Forexample, requests may be received to change one or more data nodeswithin a hierarchical data system associated with a first application.In response to such requests, the affected hierarchical data systems maybe determined based on one or more shared data mappings between thefirst hierarchical data system and each of the affected hierarchicaldata systems, and one or more data administrator users for each of theaffected hierarchical data systems may be identified and retrieved.Various automatic approval request notifications may be generated andtransmitted to each of the data administrator users for each of theaffected hierarchical data systems, and responses (e.g., approvals) maybe received from the various data administrators to the requests tochange the data nodes within the hierarchical data system.

Additionally, certain techniques described herein relate to applicationmaterialization within hierarchical systems. By way of example, systemfunctionality may be implemented to allow users to interact with theirdata hierarchies and master data through management of materialized,application-centric views. In some cases, a single user interface may beprovided to allow users to perform both application materialization ofthe user's applications, and master data management. For example, insome embodiments, requests may be received to output the datahierarchies associated with a particular application. In response, theserver system may determine that the particular application subscribesto at least one data dimension maintained by an external application,and then retrieve the subscribed-to data nodes of the externalapplication. The server system then may combine the data nodes retrievedfrom the external application with various application-level datahierarchies maintained by the particular application, and generate andoutput one or more graphical interface representations of the requesteddata hierarchies, including combination of data nodes retrieved from theexternal application with the application-level data hierarchiesmaintained by the particular application.

Further techniques described herein relate to native support for dataintersections as first-class objects, including data intersectionmastering. In some embodiments, requests may be received and process foraccessing particular intersection data nodes within data dimensionsassociated particular hierarchical applications. Such dimensions mayinclude one or multiple intersection data nodes. In response, the systemmay determine that the dimension associated with the applicationcorresponds to a shared master data dimension within a hierarchicalmaster data store, and may access the shared master data dimension via ahierarchy management server. Additionally, the system may retrieve, viathe hierarchy management server, the requested intersection data nodesfrom the shared master data dimension within the hierarchical masterdata store, and provide the requested intersection data nodes to theparticular hierarchical applications. Certain related techniquesdescribed herein include the visualization of change requests withinhierarchical systems. For example, requests also may be received andprocessed for updating data within data hierarchies associated withhierarchal application. In response to such requests, the system maydetermine one or more additional data hierarchies affected by therequested data update, wherein the additional data hierarchies may beassociated with the current application and/or various externalapplications. The system may retrieve the additional data hierarchiesassociated with the external applications, and may generate and/oroutput graphical interfaces including representations of the datahierarchies associated with the particular application and therepresentations of the additional data hierarchies associated with theexternal applications within the same graphical interface. In somecases, the graphical interfaces may further include graphicalrepresentations identifying the requested data update within each of thedata hierarchy representations shown in the graphical interface, as wellas various additional features related to analyses and visualization ofchange requests within hierarchical data systems.

Still additional techniques described herein relate to hierarchypreparation including various intelligence components and automatedprocesses for importing data into hierarchical data systems, in order toensure referential integrity of the hierarchy and all hierarchyentities. For example, in some embodiments, input may be receivedidentifying data sources for importation and/or target data hierarchywithin hierarchical master data stores for the requested dataimportation. In response to the inputs, the system may access thevarious data sources, and load data from each of the data sources intotemporary storage associated with the hierarchical master data store.Further, the system may execute various validations and/or grid actionson the data loaded into the temporary storage, after which the loadeddata may be imported from the temporary storage into the target datahierarchies within the hierarchical master data store.

Further areas of applicability of the present disclosure will becomeapparent from the detailed description provided hereinafter. It shouldbe understood that the detailed description and specific examples, whileindicating various embodiments, are intended for purposes ofillustration only and are not intended to necessarily limit the scope ofthe disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an example hardware and/or software architecture, inaccordance with certain embodiments described herein.

FIG. 2A is a diagram representing a hierarchical data system withoutshared reference data, in accordance with certain embodiments describedherein.

FIG. 2B is a diagram representing a hierarchical data system withoutshared reference data, in accordance with certain embodiments describedherein.

FIG. 3 is a hierarchical diagram representing an example producthierarchy, in accordance with certain embodiments described herein.

FIG. 4 is a flow diagram illustrating an example process of incrementalrationalization, in accordance with certain embodiments describedherein.

FIG. 5 is a flow diagram illustrating an example process of determiningwhen and how application-level data dimensions may be mastered within anorganization, in accordance with certain embodiments described herein.

FIG. 6 is a flow diagram illustrating an example process of combiningtwo node types, in accordance with certain embodiments described herein.

FIG. 7 is a flow diagram illustrating an example process of generatingcontextual pools in response to change requests, in accordance withcertain embodiments described herein.

FIG. 8 is an example state diagram illustrating a state machine forprocessing change requests, in accordance with certain embodimentsdescribed herein.

FIG. 9 is an example object model that may be used to handle theprocessing of change requests, in accordance with certain embodimentsdescribed herein.

FIG. 10 is a flow diagram illustrating an example process of generatingcontextual pools in response to change requests, in accordance withcertain embodiments described herein.

FIG. 11 is an example screen of a user interface illustrating variousapplication materialization techniques, in accordance with certainembodiments described herein.

FIG. 12 is another example screen of a user interface illustratingvarious application materialization techniques, in accordance withcertain embodiments described herein.

FIG. 13 is another example screen of a user interface illustratingvarious application materialization techniques, in accordance withcertain embodiments described herein.

FIG. 14 is a block diagram illustrating the relationship between anapplication adapter and a view, in accordance with certain embodimentsdescribed herein.

FIG. 15 is a hierarchical diagram showing an example portion of a datahierarchy in which a number of intersection data nodes are represented,in accordance with certain embodiments described herein.

FIG. 16 is a flow diagram illustrating an example process forvisualizing, reviewing, and processing data change requests from anapplication, in accordance with certain embodiments described herein.

FIG. 17 is an example screen of a user interface displaying anapplication view in the context of a particular change request, inaccordance with certain embodiments described herein.

FIG. 18 is another example screen of a user interface displaying anapplication view in the context of a particular change request, inaccordance with certain embodiments described herein.

FIGS. 19A and 19B are example screens of a user interface illustratingtechniques for operation visualization, in accordance with certainembodiments described herein.

FIG. 20 is another example screen of a user interface illustratingtechniques for operation visualization, in accordance with certainembodiments described herein.

FIG. 21A is another example screen of a user interface illustratingtechniques for operation visualization, in accordance with certainembodiments described herein.

FIG. 21B is another example screen of a user interface illustratingtechniques for operation visualization, in accordance with certainembodiments described herein.

FIG. 22 is a flow diagram illustrating an example process of hierarchypreparation, in accordance with certain embodiments described herein.

FIG. 23 is a simplified diagram of a distributed system, in accordancewith certain embodiments described herein.

FIG. 24 is a simplified block diagram of components of systemenvironment in which services may be offered as cloud services, inaccordance with certain embodiments described herein.

FIG. 25 is an exemplary computer system, in accordance with certainembodiments described herein.

DETAILED DESCRIPTION

The present disclosure relates to techniques (e.g., methods, systems,non-transitory computer-readable storage memory storing a plurality ofinstructions executable by one or more processors, etc.) for storing andmanaging master data in hierarchical data systems. Several separate butrelated concepts, embodiments, and examples are discussed in thefollowing sections, including (1) an overview of data mastering in ahierarchical data model, (2) techniques for incremental rationalizationin a hierarchical data model, (3) techniques for implementing governancepools in a hierarchical data model, (4) techniques for applicationmaterialization in a hierarchical data model, (5) techniques for dataintersection mastering in a hierarchical data model, (6) techniques forchange request visualization in a hierarchical data model, and (7)techniques for hierarchy preparation in a hierarchical data model.

Overview of Data Mastering in Hierarchical Systems

As noted above, various techniques described herein relate to storingand managing master data in hierarchical data systems. For example, asingle organization may operate multiple different systems forreceiving, storing, analyzing, and outputting data. Such systems mayrelate to any aspect of the organization, including business-relatedsystems, employee-related systems, customer-related systems,vendor-related systems, product-related systems, systems relating to thetechnical infrastructure of the organization, etc. Additionally, anorganization's systems may be heterogeneous, so that each system has itsown hierarchy or hierarchies of reference data, and each hierarchy mayorganize different or overlapping sets of reference data according todifferent criteria. These heterogeneous systems may have no knowledge ofthe hierarchies employed by other systems, even if a portion of thereference data overlaps.

Referring now to FIG. 1 , an example hardware and/or softwarearchitecture 100 is shown on which certain master data storage andmanagement techniques described herein may be implemented. In thisexample, architecture 100 includes one or more data management systems120 configured to access data from one or more data stores 110-112. Datamanagement systems 120 may include a plurality of separate (e.g.,heterogeneous) systems 121-124, which in this example are shown ashierarchical data systems 121-124. As discussed above, systems 121-124may correspond to data systems of an organization's business-relatedapplications, employee management applications, resource managementapplications (e.g., server management, computer network management,etc.), and/or any other specialized hardware/software systemsimplemented for an organization.

Data stores 110-112 may be databases (e.g., Microsoft SQLServer, Oracle,Sybase, ODBC or other database known in the art). Additionally oralternatively, data stores 110-112 may be cloud-based data sources, andone or more systems 121-124 may correspond to cloud applications. Thus,the hierarchy management server 130 may be configured to natively pushdata to and/or pull data from such external applications, and tovalidate that the data is correct and complete for the integratedapplication. This may include the ability to register externalapplications with the hierarchy management server 130, so that theexternal applications may play the role of publisher and/or subscriberin the data management process. Certain non-limiting examples ofcloud-based applications that may be supported in such embodimentsinclude, for example, ORACLE Planning and Budgeting Cloud Service(PBCS), ORACLE Enterprise Performance Reporting Cloud Service (EPRCS),ORACLE Financial Consolidation and Close Cloud (FCCS), ORACLE HyperionFinancial Data Quality Management, Enterprise Edition (FDMEE), andORACLE Fusion General Ledger (G/L), among others.

Additionally, architecture 100 may include a reporting system 150 toreport data to client various client devices 160 (e.g., human orprogrammatic users). Each hierarchical data system 121-124 may use itsown hierarchy of reference data to store, access or report on data ofinterest from data sources 110-112. Architecture 100 can further includean Extract Transform Load (ETL) system 140 to extract data from datamanagement systems 120 and format the data to the hierarchy of reportingsystem 150.

As discussed above, data systems 121-124 may be implemented as separateand heterogeneous systems, and may have little or no intercommunicationand little or no knowledge about the other systems 120. Nonetheless, twoor more of the systems 120 may be implemented using a hierarchical datamodel, and there may be certain overlap in the reference data of systems121-124. For example, a financial data system 121 may use a hierarchy toorganize particular expenses, and the data hierarchy may includereference data related to the line of business (LOB) structure of theorganization (e.g., related to departments, divisions, sections and soon), etc. Additionally, a separate costing system 122 may use a datahierarchy to organize data which includes reference data related to thegeographical location at which particular expenses occur. While somepieces of reference data may overlap between these two hierarchies,financial data system 121 may have little or no knowledge about thecosting system's 122 hierarchy, and the costing system 122 may havelittle or no knowledge about the financial data system's 121 hierarchy.

In this example, the software and/or hardware architecture 100 mayinclude a hierarchy management server 130, which may be implemented aspecialized hardware server, specialized software (e.g., a hierarchymanagement program), and/or a combination of specialized hardware andsoftware. The hierarchy management server 130 may manage the multiplehierarchies of architecture 100, and may maintain a master set ofreference data in a master data store 135, representing the hierarchicalreference data used by source data management systems 121-124. In someembodiments, the hierarchy management server 130 may use the master datato instantiate centralized hierarchies and publish the centralizedhierarchies to systems 121-124. Centralized hierarchies can bemaintained, analyzed and validated before being sent to subscribingsystems. In some cases, the hierarchy management server 130 also mayformalize hierarchy management, for example, by maintaining a hierarchyobject model for hierarchy management. The hierarchy object model mayinclude representations of reference data across hierarchies (referredto “global nodes”) and representations of the reference data in aparticular hierarchy (referred to as a “local nodes”). As discussedbelow, the hierarchy object model may associate properties withparticular pieces of reference data and can enforce inherencies betweenproperties across different levels of a hierarchy and acrosshierarchies.

Hierarchy management server 130 may serve as the “system of record” forhierarchical reference data, and may reconcile hierarchical referencedata from different source data management systems 121-124, etc. In someembodiments, the hierarchy management server 130 may publishhierarchical reference data for loading into selected systems 121-124,and may load hierarchical reference data from systems for audit andvalidation purposes. The system in a particular software architecture towhich the hierarchy management server 130 may publish data, or fromwhich the hierarchy management server 130 may load data, can be definedto suit the needs of a particular organization.

As part of maintaining the master data for the hierarchical system, thehierarchy management server 130 may receive and process hierarchy changerequests associated with individual hierarchies. As noted above,individual hierarchical data systems 121-124 may have no knowledge ofthe hierarchies of other data systems 121-124, yet it may be desirable(and/or required) for changes in one of these data hierarchies to bereflected in one or more other hierarchies. Therefore, after receiving achange request, the hierarchy management server 130 may determine one ormore additional hierarchies affected by the requested change, updatedthe additional hierarchies to reflect the change, and validate thechange in the first requested hierarchy and the additional affectedhierarchies. In this example, the hierarchy management server 130 mayprovide various technical advantages, for example, by allowinginherencies to be enforced within a hierarchy and across hierarchies, bybeing able to automatically apply business rules and validations acrossmultiple hierarchies, and/or by automatically propagating hierarchychanges across multiple hierarchies.

Master data store 135 may include a copy of all the pieces of referencedata being managed by hierarchy systems 121-124. Thus, the master datastore 135 may maintain copies of data for the individual hierarchieswithin systems 121-124. Duplicate copies of particular pieces ofreference data can be maintained in the master data store, or a singlecopy of a piece of reference data that appears in multiple hierarchiescan be maintained. For example, a single copy of a piece of referencedata can be maintained for multiple hierarchies, or a copy can bemaintained for each hierarchy 121-124. Additionally, propertiesassociated with each piece of reference data, the relationships betweenpieces of reference data for various hierarchies, business rules andother arbitrarily defined rules that apply to each hierarchy may bemaintained by the hierarchy management system 130.

In some embodiments, hierarchy management system 130 may retrieve datafrom and/or provide data to the individual subscribing data systems121-124, one or more ELT systems 140, and/or one or more reportingsystems 150. Data hierarchies (or just “hierarchies”) may be publishedto subscribing systems in specific formats based on the particularsubscribing system (e.g., readily loadable formats specific to thesubscribing system). For example, if hierarchy is established atparticular hierarchical data system 121, the hierarchy may includepieces of reference data, and associated properties and relationships.The hierarchy management system 135 may import the reference data,properties and/or the relationships from the data system 121. By storingpieces of reference data, relationships and properties, for eachhierarchy being managed, hierarchy management server 130 may maintain amaster set of reference data, and/or may instantiate centralizedhierarchies that correspond to the individual data hierarchies withinsystems 121-124. Centralized hierarchies may be used to manage thehierarchies of subscribing systems.

As noted above, the hierarchy management server 130 may instantiate oneor more centralized hierarchies from a master set of reference datawithin master data store 135. Each centralized data hierarchy mayrepresent one or more hierarchies within subscribing systems 120.Additionally, changes to particular hierarchies (e.g., either acentralized data hierarchy or a hierarchy within a subscriber system120) may be propagated to the other related hierarchies, and suchchanges may be validated across hierarchies. For example, when adding anew data item to a particular hierarchy (e.g., within a particular datasystem 121), the new data item may be added to other correspondinghierarchies (e.g., a centralized data hierarchy and/or correspondinghierarchies with other data systems 120) as well. For example, thehierarchy management system 130 may import the changes into the masterset of reference data in the master data store 135. After importing theupdated data, the hierarchy management system 130 may apply a definedset of rules to the updated master hierarchy to determine if thehierarchy is valid. If the centralized hierarchy is valid, the hierarchymanagement system 130 may determine other hierarchies to which the newpiece of reference data should be added, and also may determine theassociated parameters and relationships to be added. Business rulesassociated with a hierarchy of an individual data system (e.g., 121) maybe applied to determine if a piece of reference data is valid to beadded to the corresponding centralized hierarchy in the master datastore 135. If the new piece of reference data is a valid addition to thecentralized hierarchy, the hierarchy management system 130 may exportthe centralized hierarchy to the other affected systems (e.g., 122-124)to update their individual data hierarchies. However, if the newaddition to the centralized hierarchy is not valid, then the hierarchymanagement system 130 may notify the individual system (e.g., 121) thatrequested the data addition that the update is invalid. In this case,the hierarchy management system 130 may export an earlier version of acentralized hierarchy that did not include the new piece of data to theother affected systems (e.g., 122-124), to restore the originalhierarchy on all affected systems.

In some embodiments, a validation may be performed for each centralizedhierarchy in which a particular change will appear. For example, if anaddition at a data hierarchy of an individual system 121-124 isdetermined to also affect a centralized hierarchy in the master datastore 135, then a validation process may be initiated on the centralizedhierarchy before the hierarchies of other subscribing systems 121-124are updated. If the change to the centralized hierarchy is determined tobe valid, according to predefined rules associated with the centralizedhierarchy, then the change may be propagated to correspondinghierarchies in the other individual systems 121-124. In some cases, newpieces of reference data may be added into one or more of thesubscribing systems 121-124 (and then retrieved by the hierarchymanagement system 130), while in other cases the hierarchy managementsystem 130 may directly receive the hierarchy changes. In either case,the addition of a new piece of reference data may be added directly tothe appropriate centralized hierarchy stored within the master datastore 135. The centralized hierarchy may be validated, after which thechange may be propagated to any other affected centralized hierarchiesin the master data store 135, and those other centralized hierarchiesalso may be validated. If the changes are valid across all of theaffected centralized hierarchies, then the hierarchy management system130 may export the updated hierarchies to each of the subscribing datasystems 121-124 that stored corresponding hierarchies. Additionally,when an update is made to one or more of the centralized hierarchies,the hierarchy management system 130 also may generate new ETL mappings,and may publish the ETL mappings to ETL system(s) 140. Thus, thehierarchy management system 130 may become the point of input for allhierarchy changes, thereby allowing hierarchy changes to be receives,entered, propagated (internally within the centralized master data), andvalidated at a single system before the change is propagated to theother (external) subscribing systems 120 across the organization.

Thus, the hierarchy management system 130 may act as a hub wherecentralized hierarchies may be maintained, analyzed and validated,before being sent to various subscribing systems 120 (e.g., any systemsor applications that push data to or pull data from hierarchy managementsystem 130). Hierarchy management system 130 may manage hierarchies andalternate views, and may store additional information used to support asubscribing system, for example, alternate names and descriptions,formulas, allocation mechanisms and percentages and aggregation methods.In some embodiments, the hierarchy management system 130 also mayprovide users with a single point of access to manage the hierarchiesfor all or for certain selected applications across an organization,thereby simplifying and consolidating the tasks of hierarchy management.Hierarchy management system 130 also may be used to manage hierarchicalreference data (e.g., chart of accounts, cost center rollups, productstructure, customer relationships and other hierarchical reference data)and other reference data mappings (old G/L account to new G/L account).

In some embodiments, for some or all of the centralized data hierarchiesstored in the master data store 135, the hierarchy management system 130may maintain multiple versions of the hierarchy. In such cases, thehierarchy management system 130 may maintain reference data,relationships and/or properties for each version of a particularcentralized hierarchy, as well as data identifying the changes that haveto that centralized data hierarchy over time. Such versioningcapabilities may allow the hierarchy management system 130 to access andprovide older versions of a centralized data hierarchy, and/or toidentify the previous changes that have been made to the centralizedhierarchy over time. The hierarchy management system 130 also maymaintain a set of permissions associated with the each of thecentralized hierarchies stored in the master data store 135, includingpermissions associated with particular versions of the centralizedhierarchies and/or permissions associated with particular pieces ofreference data. In such embodiments, only users with the appropriatepermissions may be permitted to update a particular centralizedhierarchy, version, or piece of reference data.

Additionally, for particular nodes with data hierarchies, the hierarchymanagement system 130 may compare property values of the particular nodeto criteria. Such property values may be accessed from a local node(e.g., a particular node within a subscriber data system 120), acorresponding global node, or a controlling hierarchy. In someembodiments, in order to access (and/or set) properties, the hierarchymanagement system 130 may traverse up the hierarchy based on the parentsof each node, or down the hierarchy based on the children listed in eachnode. In some embodiments, the processes for hierarchy traversal may beimplemented as defined classes that can be associated with a hierarchyin, for example, a hierarchy object. Additionally, the hierarchymanagement system 130 may include defined processes for exporting datarelating to particular hierarchies. Thus, certain techniques describedherein may apply various business, validation and export rules tohierarchies. Further, when a local node is analyzed, property values maybe accessed directly from the local node, from a global node or fromother hierarchies so that property values do not have to be redundantlystored.

Incremental Rationalization in Hierarchical Systems

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) described herein relate toincremental rationalization of hierarchy data. Data rationalizationrefers to the process by which pieces of reference data stored withinthe data hierarchies of individual systems 121-124, are extracted fromthe individual systems and added to the master data of the organization.That is, if multiple different data hierarchies maintained by systems121-124 share overlapping reference data, then the pieces ofoveralapping reference data may be extracted from the individual systemhierarchies and added to a centralized hierarchy within the master datastore 135. For example, if a first user operates a first applicationassociated with the hierarchical data system 121, and a second useroperates a second application associated with a different data system122, agreement may be reached between the two systems to share theiroverlapping data. For instance, assuming that both data systems 121 and122 operate systems associated with the same organization, they mayshare a common set of reference data representing the organization'soffices, data centers, computer servers or devices, locations,employees, customers, stores, products, or suppliers, etc. Although thisorganization data may periodically change, it may be determined by oneor both systems that there are technical advantages to maintaining asingle copy of the date within a centralized hierarchy, rather thanmultiple copies of the data within the individual systems 121 and 122.Thus, after determine which reference data hierarchies are to berationalized, the respective data nodes, along with the metadataproperties, hierarchical relationships, etc., may be shared byrationalizing the data into a master data store 135. Nonetheless, asdescribed below in more detail, each user and/or subscriber system 120may maintain their own preferred views and terminologies for the sharedrationalized reference data. The incremental rationalization techniquesdescribed herein thus may provide advantages by allowing end users,which may refer to human and/or programmatic clients, to makerationalization decisions (e.g., bilateral or multi-lateralrationalization determination) on the fly and during the ongoingoperation of their respective systems 120, rather than having toinitially make rationalization determinations. Additionally, in certainembodiments, the hierarchy management system 130 may support branchingfeatures which allow end users to view and evaluate rationalizationscenarios before finally committing to the rationalization.

Referring briefly to FIGS. 2A and 2B, a set of diagrams is shownillustrating an example of master data rationalization. In theseexamples, the application data sets 221 and 222, and the master data set235, may be in the form of tables and databases, where the rows of thetables may represent data nodes (or data entities) and the columns ofthe table may represent various data dimensions. A data dimension is aset of related data values, such as the values in a column of a databasetable, or correlated fields in an XML, file that are marked with acommon tag, and thus may represent different values, properties, orattributes of the same type. For instance, in a data systemcorresponding to a eCommerce and/or retail business or organization,data dimensions may correspond to different sets of reference datarelevant to the organization, such as the set of all customers, the setof all employees, the set of all products, the set of all product lines,the set of all stores, the set of all sales representatives, the set ofa data centers, etc. In some cases, data dimensions may be organizedinto one or more data hierarchies, such as products to product lines toproduct manufacturers, stores to states to regions to countries,employees to departments to business units, and so on. A data dimensionthus may represent a single tier/level within a larger data hierarchy,or may represent multiple tiers/levels.

In this example, the link point across the master and application levelsmay be by node, where an application node (i.e., a particular data nodewithin a data hierarchy of a system or application 121-124) points to amaster node (i.e., a node within a centralized data hierarchy within amaster data store 135). In some embodiments, the hierarchy managementsystem 130 may be configured so that application nodes may be linkedwith (e.g., may point to) one and only one master node, while eachmaster node may be linked to by any number of separate applicationnodes. In some cases, a master node may be created with no applicationnodes initially pointing to it, but only after one or more incrementalrationalizations have been performed will the master node haveapplication nodes linked to it. Referring to the example diagram in FIG.2A, two hierarchies 221 and 222 are represented corresponding to twoseparate hierarchical data systems (e.g., 121 and 122). FIG. 2A alsoillustrates that no reference data is shared between the data systems,and thus the master data store is empty 235. Referring now to FIG. 2B,at a later time as rationalization progresses within the data systemsexecuting on the architecture 100, each incremental rationalizationprocess causes shared nodes, properties, and relationships to begenerated within the master data store 235, and correspondingly the dataof each subscribing system 221 and 222 may be reduced. As this exampleillustrates, the overall number of objects that are stored within thearchitecture 100 may be reduced as the amount of reference data sharingincreases via rationalization processes. This is a reflection of reducedmaintenance complexity, and demonstrates a movement in the direction ofdimension maturity.

The two-level model illustrated in this example may provide the abilityfor data in the master data store 235 to be shared across multiple datasystems/applications 120, while at the same time allowing theapplications to override the parts of the dimension that areapplication-specific. In some embodiments, newly registered datasystems/applications 120 operating within the architecture 100 may bepermitted to remain out of the mastering process for an predeterminedinitial period of time, during which they maintain their own separatereference data hierarchies without any sharing or mastering. After theinitial period of time, the data systems/applications 120 may bepermitted (or may be required in some cases) to use the correspondingshared central data hierarchies in the master data stores 135.Additionally, in some embodiments, similar application overridecapabilities (e.g., allowing individual data systems/applications 120 toopt out of the data mastering) may be supported for node propertyvalues, including node name and description, even when not supported forthe nodes themselves. Additionally, in some cases, even aspects of theproperty definition may be able to be overridden by independent datasystems 120. In such embodiments, the ability to override a node name atthe application level for all nodes may provide a built-in mechanism forspecific naming conventions by an application 120.

In some embodiments, application nodes that have been mastered may haveboth an application node type (stored at the subscriber data system 120)and a master node type (stored at the master data store 135). In somecases, this may be implemented not as an override, but as two separatenode type values, both of which available at the node. Support such nodetype dualities may provide the ability for nodes to get property valuesfrom both the application level and the master level. Additionally,supporting two separate node types may allow both types to contribute toa node's validations and user group security. The supporting of bothapplication and master levels also may allow chunk objects to berationalized, as described in more detail below. For instance, aparticular node may have a “PBCS.CostCenter” node type at theapplication level, while having a “Cost Center” node type at the masterlevel. Such examples may allow the initial node set and hierarchy setcreated during the data import to reference PBCS.CostCenter nodes fortheir rules and filtering, while at the same time allowing the eventualmaster node sets and hierarchy Sets to refer to Cost Center masternodes.

Further, two-tier models as described above also may allow the abilityfor an organization to control which values may be overridden byindividual applications, and which value may be required to come fromthe master data. For example, an organization may determine tostandardize certain descriptions for a set of products (or any otherreference data) across all subscriber systems 120, so that these can bemanaged at the master level 130-135 and pushed down to all subscribersystems 120 with no override capability, thereby ensuring consistencyfor the reference data across the applications of all subscriber systems120. As discussed in more detail below, in order to support thistwo-tier mastering approach, the hierarchy management system 130 maycreate a set of chunk objects for each subscriber system/application120, and a set of chunk objects for each master.

Further, implementations such as the example architecture 100 may alloworganization users to implement and begin using various data systems121-124 independently, without any up-front data rationalization and/orother configuration. Rather than requiring up-front datarationalization, end users (e.g., individual users or administrators ofsubscriber systems 120) may subsequently have the ability to rationalizetheir data with other 120 and/or the master 130-135 in order to createefficiencies in the management of master data and to reduce themaintenance effort. Accordingly, various rationalization tools may beimplemented and supported within the architecture 100 to allow users tocombine and share data nodes, properties, and/or hierarchies, all withina controlled and governed framework. In some embodiments, the hierarchymanagement system 130 may support automated tools to allow users toinitiate and perform incremental data rationalizations (e.g., forindividual reference data hierarchies) across multiple systems 120 of anorganization. Such incremental rationalizations may occur organicallythrough incremental efforts of end users and administrators ofsubscriber systems 120, as opposed to requiring an up-front andcomprehensive matching and rationalization effort.

In such embodiments, the hierarchy management system 130 may provide oneor more software tools to allow end users (e.g., human or programmaticsoftware clients) to identify an existing data system/application121-124 (e.g., a cloud-based application), and then provide an interfaceto allow the dimensions of the system/application to be managed. Forinstance, the hierarchy management system 130 may provide a set ofrationalization tools that allow end users to “evolve” the data and datamanagement process as they use the various applications/systems 121-124of the organization. Using such rationalization tools, the hierarchymanagement system 130 may allow administrative users to load data fromapplications 121-124 without little or no pre-load implementationconfiguration. Users also may be able to import dimensions from existingsystems/applications, text files, spreadsheets, or database tables withlittle or no implementation setup (e.g., only the import processrequirements). In such cases, the importing of data fromapplications/systems 121-124 may itself create the requisite chunk(s)(e.g., nodes types, hierarchy sets, node sets, views, and view sections,etc.) that allow dimensions to be imported and immediately managed viathe hierarchy management system 130. Additionally, in some embodiments,governance for all changes may be enabled and in effect concurrentlywith the start-up of the application.

Referring now to FIG. 4 , a flow diagram is shown illustrating anexample process of incremental rationalization in accordance withcertain embodiments described herein. As discussed below, steps 401-404in this process each may correspond to separate processes implemented byvarious components within an organizational architecture 100 for sharingand managing data hierarchies. In some cases, a data dimension/hierarchysharing may progress from step 401 to 404 as shown in this example,while in other cases the entities involved (e.g., externalapplications/data systems 120, the hierarchy management system 130,other application-level and organization-level administrators, etc.) mayimplement only step 401, 402, 403, or 404 for the datadimension/hierarchy sharing solution.

In step 401, a first application 121 executing within the distributedsystem 100 may request and receive access to one or more data dimensionsand/or hierarchies of a different application 122 within the system 100.For example, two end users or administrators of different applications120 executing within the same organization infrastructure 100 maydetermine that both applications 120 maintain one or more similarapplication-level data hierarchies. For instance, application users oradministrators may communicate to determine that both applicationsmaintain and user a product dimension/hierarchy 300, or an employeedimension/hierarchy, a customer dimension/hierarchy, etc. In such cases,one or both of the users/administrators of the applications may grantpermissions to the other application 120 to view the correspondingdimension/hierarchy. Thus, each application may evaluate the quality oftheir own data dimension/hierarchy, and may revise their own datadimension/hierarchy based on the corresponding data dimension/hierarchyof other applications 120. In these examples, neither the hierarchymanagement system 130 nor any other organization-level administratorneed be involved to implement the application-to-application permissionsin step 401.

In step 402, two or more applications 120 executing within thedistributed system 100 may request and receive sharing permissions andnotifications for their respective data dimensions/hierarchies.Continuing the above example, if an administrator of a first application121 determines that a corresponding data dimension/hierarchy in a secondapplication 122 is valuable, the first application 121 may register forsharing and notifications of changes to the corresponding datadimension/hierarchy of the second application. For instance, if aproducts hierarchy 300 (or any other data dimension or hierarchy) ischanged within the second application 122, then the first application121 may receive a notification of the change and/or permissions toimport the change into the first application's 121 own productshierarchy 300. In some cases, the individual applications 120 may beconfigured to provide real-time notifications (e.g., via email, text, orapplication-based notifications) to authorized users of otherapplications 120 that have registered for sharing permissions andnotifications. The notifications may contain data describing the changesto the corresponding data dimension or hierarchy, or may direct theauthorized user to another location (e.g., via a URL or applicationadmin link) to a separate display screen graphically representing thechanges to the data dimension or hierarchy of the other application 120.From the notification and/or related user interface, the authorized userof the first application 121 may view and accept (or deny) the changesfrom the second application 122, so that the changes to the shared datadimension/hierarchy of the second application 122 may be automaticallyimported into the corresponding data dimension/hierarchy of the firstapplication 121.

In step 403, two or more applications 120 executing within thedistributed system 100 may implement an automated subscription processfor a pair of similar or related data dimensions/hierarchies. Anautomated subscription process may be similar to the sharing permissionsand notification process described above in step 402. However, afterreaching a high level of confidence with a shared datadimension/hierarchy, a sharee (or recipient) application may determinethat notifications are no longer needed and all changes from the datadimension/hierarchy of the sharer application 122 should automaticallybe transmitted and imported into the corresponding datadimension/hierarchy of the sharee application 121. The automatic receiptand important of changes from an external data dimension/hierarchy intoan internal data dimension/hierarchy of an application 121 may bereferred to as a subscription. As in the data hierarchy sharingprocesses described above in steps 401 and 402, the automatedsubscription process in step 403 need not involve the hierarchymanagement system 130 or any other organization-level administrativeprocess. Rather, any of the data hierarchy sharing processes of steps401, 402, and/or 403 may be performed autonomously (and incrementallyfrom 401-403, if desired) by any combination of applications 120.

In step 404, data dimensions/hierarchies from one or more of theexternal applications 120 may be designated as shared master data andimported into the master data store 135 by the hierarchy managementsystem 130. For example, if two or more applications 120 operatingwithin the organization computing infrastructure 100 are sharing thesame data dimensions/hierarchies (e.g., via sharing and notifications instep 402, or automated subscriptions in step 403), the hierarchymanagement system 130 may determine that the data dimensions/hierarchiesshould become master data and made available to the applications 120through a centralized master data store 135 and/or hierarchy managementsystem 130 of the organization infrastructure 100. The determination toimport data dimensions/hierarchies of one or more applications 120 intothe master infrastructure may be initiated by a request from one or moreapplications 120, by application-level or organization-leveladministrators, and/or by automated processes executing with thehierarchy management system 130.

As discussed above, when data dimensions/hierarchies of applications 120are imported into the master data store 135, the correspondingapplication-level data dimensions/hierarchies may be deleted. Thus,after the data has been mastered, an application 120 requiring access tothe data dimension may retrieve the shared master data dimension usingthe hierarchy management system 130. In some cases, applications 120 maybe permitted to keep their corresponding application-level datadimensions/hierarchies rather than deleting them from the applicationstorage. For example, certain applications 120 may be permitted toappend and/or override data from the master with their own datadimensions/hierarchies. As another example, an application 120 may bepermitted to maintain and apply an additional (or alternative) set ofdata node properties, which may be applied by the application to thenodes of the data dimension(s) retrieved from the master. Thus, certainapplications 120 may be permitted to append or override the data nodesproperties, instead of or in addition to appending or overriding thedata nodes themselves. In other embodiments, some or all of the externalapplications 120 operating within the organization computinginfrastructure 100 may be required to use the shared master datadimension as is, without altering or appending any additional datanodes, properties, or relationships, to the shared master datadimension.

The determination to “master” one or more data dimensions/hierarchiesfrom an application 120, by importing the data into the master datastore 135 and providing access to the data via policies in the hierarchymanagement system 130, may be performed by automated processes, manualprocesses, or a combination of automated and manual processes. Forexample, referring now to FIG. 5 , an example flow chart is shown fordetermine when and how application-level data dimensions may be masteredwithin the organization infrastructure. In this example, the hierarchymanagement system 130 (alone or in communication with the externalapplications 120) may monitor the various data dimensions being shared,copied, and subscribed to among of the applications 120. For example, instep 501, the hierarchy management system 130 may determine that aparticular data dimension or hierarchy maintained by a first application121 is being subscribed to by three additional applications 122-124. Insome embodiments, the system data regarding the number differentapplications 120 sharing and/or subscribing to datadimensions/hierarchies of other applications 120 may be periodicallymonitored by the hierarchy management system 130, for example, byperiodically requesting and received subscription and/or sharing datafrom each of the applications 120. In step 502, if the hierarchymanagement system 130 determines that a particular data dimension orhierarchy maintained by a first application 121 is being shared, copied,or subscribed to by more than threshold number of other externalapplications 120 (502:Yes), then the hierarchy management system 130 maydetermine that the data dimension or hierarchy should be imported intothe shared master data hierarchies in the master data store 135. In step503, the particular data dimension or hierarchy from the application 121is imported into the shared master data store 135, and in steps 504-505the corresponding data dimensions/hierarchies are deleted from theapplication 121 that previously maintained the data dimension/hierarchy(step 504) and the other applications 120 that has previously subscribedto the data dimension/hierarchy of the first application 121 (step 505).

In the example of FIG. 5 , each of the affected applications 120 may benotified and their subscriptions changed so that the datadimension/hierarchy will be retrieved from the hierarchy managementsystem 130 and master data 135. However, in other examples, certainapplications 120 may be permitted to keep and use some or all of theircorresponding data dimension/hierarchy. For example, the hierarchymanagement system 130 may determine that some but not all of the datanodes from the data dimension of the first application 121 should beimported to create the shared master data dimension. In this case, thefirst application 121 may be permitted to maintain an application-leveldata dimension/hierarchy with the non-mastered data nodes, that can becombined with the mastered data dimension/hierarchy, so that the datadimension/hierarchy of the application does not change. As discussedabove, in other examples, certain applications may be permitted tomaintain corresponding an application-level data dimension/hierarchy,which may include a different set of data nodes and/or properties thatmay override or be appended to the master data hierarchy.

Using the hierarchy management system 130 to centrally manage the datahierarchies of multiple subscriber applications 121-124 may potentiallyprovide the advantages of a single point of maintenance for the sharedreferences data, as well as lowering the overall storage requirements ofthe organization. The incremental rationalization process, by whichusers and their corresponding applications may make agreements to beginsharing data and metadata between applications 121-124, may movemaintenance processes that are initially siloed gradually towardscentralized master processes, thereby potentially gaining efficienciesin these processes. Rather than an application moving its reference datafrom siloed to fully rationalized at once, the hierarchy managementsystem 130 may allow users to evolve their reference data hierarchies(or dimensions) from siloed to fully rationalized over time, byrationalizing individual data hierarchies (or portions thereof) and/orindividual corresponding metadata properties and relationships, thusresulting in as little data disruption as possible. Additionally, thehierarchy management system 130 may be configured to handle theevolution process without requiring external data transformationprocesses or large manual metadata changes. In some embodiments, thehierarchy management system 130 may be configured to monitor the datasystems/applications 120 within the organization, but to allow each newapplication 120 to be deployed and to initially execute independently(e.g., without knowledge of or data conflicts with any otherapplications 121-124). Then, at a later time, the new datasystems/applications 120 may start sharing data incrementally, by makingindividual determinations for each application of particular referencedata commonalities with other data systems/applications 120 in theorganization. The data sharing/mastering process thus may happenincrementally, through a series of small determinations made by endusers and/or administrators (e.g., human or programmatic) associatedwith specific applications 120, and after the initial deployment andexecution of the specific data systems/applications, rather thanimplementing top-down modeling efforts and/or performing datarationalization during initial configuration of the organizationarchitecture 100.

In some embodiments, the hierarchy management system 130 may providerationalization tools, accessible to subscriber systems/applications120, which are configured to be as non-disruptive as possible to thecontinuing operation of the systems/applications 120. For example, fromthe standpoint of an application 120 or end user/administrator, theincremental rationalization may be performed by the hierarchy managementsystem 130 so as not to affect the data nodes, relationships, orproperty values of the application's data hierarchies. Instead, theincremental rationalization processes managed by the hierarchymanagement system 130 might simply affect the way that the datanodes/properties/relationships are managed and shared. Even in suchcases, certain rationalization decisions may affect data on purpose.Thus, incremental rationalization performed by the hierarchy managementsystem 130, by which certain hierarchical reference data, properties,and/or relationships in one or more data systems 120 are determined tobe corresponding data and are transitioned from application-specificstorage to the master data store, may be performed entirelytransparently to the operation of the affected data systems/applications120. However, certain incremental rationalization processes performed bythe hierarchy management system 130 may be intentionally not transparentto the subscriber systems 120. For instance, an organizationadministrator may determines that all PBCS applications 121-124 will berequired to use the aliases from a NorthAmerica-PBCS instance. In thisexample, the applications 1210124 may see changes to their aliases.However, in some embodiments, without a specific administrative decisionto the contrary, the rationalization processes performed by thehierarchy management system 130 may be entirely non-disruptive to theoperation of the subscriber systems 120.

In some embodiments, the hierarchy management system 130 may include anumber of rationalization tools (e.g., a rationalization workbench),including tools for rationalizing (or mastering) data nodes, properties,relationships, maps, property definitions, chunks, and chunk chains. Insome cases, the hierarchy management system 130 may include a set ofsmall, single-purpose tools for each of these types of data, along withthe logic to mix and match the appropriate combinations of toolsdepending on the needs for a particular rationalization, therebyavoiding the use of a single large, unwieldy tool, and also allowingadditional rationalization tools to be added through different releasesof the hierarchy management system 130. Various examples of differenttypes of rationalizations and corresponding rationalization tools aredescribed in the following paragraphs.

Node rationalization may refer to the process of merging two or morenodes from multiple node types into a single node type. The source nodetypes can be application node types (e.g., a node type that is validwithin a subscriber system 120) or master node types(e.g., a node typethat is valid within a master data store 135), but the target node typemust be a master node type. The target master node type may alreadyexist within the master data store 135, or may be created as part of thenode rationalization process. A node rationalization software toolsupported by the hierarchy management system 130 may include settings tocontrol how the differences across the various note types are to behandled. In some embodiments, only node types of the same dimension typemay be permitted to be rationalized together.

The first step of node rationalization may be to copy the target nodesinto the source. This may include copying the nodes from an applicationnode type into a master node type (e.g., for application-to-masterrationalization), or may include copying the nodes from one master nodetype into another master node type (e.g., for master-to-materrationalization).

Referring now to FIG. 6 , a flow chart is shown illustrating an exampleprocess of combining two node types. In step 610, the hierarchymanagement system 130 may receive input (e.g., human user orprogrammatic input) selecting one or more source node types to be mergedinto a master node type. In step 620, the hierarchy management system130 may access the master data store 135 to determine whether or not themaster node type already exists. If the master node type does not exist,it may be created as part of the node type combination process in step630. In step 640, all nodes from the source node type may be copied intothe master node type. Copying nodes from one type to another mayinclude, for example, creating a new node ID, and copying the sourcenode name into the target master node name. In step 650, the hierarchymanagement system 130 may receive input (e.g., human user orprogrammatic input) selecting and/or defining one or more duplicate namerules to be used to resolve node name conflicts. A node name conflictmay occur, for example, when a particular node name already exists inthe master node type within the master data store 135. Node nameconflict rules may include, for example, prefixing and suffix options,and/or iterative numbering (e.g., using the next number in a series)until a unique node name is identified. Finally, in step 660, if thehierarchy management system 130 determines that the node typecombination is a master-to-master combination, then in step 670, thehierarchy management system 130 may copy the node name down to anysubscriber applications 120 that are linked to the source master, inorder to preserve the existing node names. For example, if ABC is asource node, and ABC already exists in the target master node type, itmay be renamed based on the duplicate name rules (e.g., to ABC.1).However, if any of the subscriber applications 120 that use the sourcemaster are getting their node name from the master, then the node nameABC may be pushed down to the application level, in order to avoid datadisruption in the form of a rename event.

In some embodiments, property rationalization may be performed afternode rationalization, and might only be available for application nodesthat are shared (e.g., linked to master nodes). Property rationalizationmay refer to techniques and processes performed by the hierarchymanagement system 130 that relate to maintaining the property valuesstored at the master level (e.g., within a master data store 135), andimplementing rules that define how those property values are cascadeddown to the subscriber applications 120. Additionally, the propertyrationalization techniques provided may allow survivorship rules to beestablished that determine how master values may be calculated based onthe accuracy and/or frequency of the application-level values.

Hierarchy rationalization may, in some embodiments, be performed afterproperty rationalization to create (or to attempt to create) commonhierarchies across applications. Various hierarchy rationalization toolssupported by the hierarchy management system 130 may include tools thatprovide end users the ability to define a hierarchy structure changes insubscriber data systems/applications 120, and/or in the masterhierarchies, and have that change affect all of the linked applications120. However, since not all nodes within all of the master hierarchiesmay necessarily be needed in all linked application hierarchies, thehierarchy rationalization processes supported by the hierarchymanagement system 130 may include filtering features that allowusers/applications to include or exclude particular nodes that are notin their hierarchies. The filing features that allow including/excludingof nodes may be controlled by mastering rules and/or ownership settingsthat may determine (1) which data systems/applications 120 are permittedto update particular hierarchies, (2) which applications may be requiredto take all changes from the master, and (3) which applications have theoption of filtering out certain nodes. Additionally, the datasystems/applications 120 that participate in hierarchy rationalizationmay be provided features around viewing nodes that have been previouslyexcluded, with options to re-include them later.

In some embodiments, hierarchy rationalization may differ in scope fromthe node and property rationalization processes described above, in thathierarchy rationalization may be implemented as an all-or-nothingprocess in some cases. For example, user-initiated incremental (orstep-wise) rationalization might not be supported for hierarchyrationalization in some embodiments, even when incrementalrationalization is supported for node and/or property rationalization.In such embodiments, users might not be provided the option of selectingone or more relationships at a time to move to the master. Instead,options may be provided to users/applications via the hierarchyrationalization tools allowing the application to subscribed to anentire hierarchy, or not to subscribe.

Additionally, in various embodiments, the hierarchy management system130 may support one or more features of hierarchy rationalizationprocesses to make those processes as non-disruptive as possible to thesubscriber applications 120. For example, in some cases, robustcomparison tools may be configured to show how many changes and filterednodes will be required to share a particular hierarchy, before thedecision to share the hierarchy is confirmed by the user/application.Additionally, the hierarchy rationalization tools may include the optionto exclude certain nodes at the application level. In some embodiments,hierarchy rationalization tools may support notification requests thatlist all changes, thereby providing users/applications advancedinformation describing how the potential hierarchy rationalization mayaffect the applications. Finally, certain hierarchy rationalizationtools may support versioning and rollback, allowing users/applicationthe option to return to a pre-rationalization state.

In some examples, it may be more efficient to rationalize hierarchiesthat have a significant portion of shared structure across differentapplication hierarchies. However, in some cases, it may be possible torationalize two hierarchies that have little or no overlap of sharedstructure. In such cases, the resulting master hierarchy set may simplyhave two top nodes with no shared relationships below them. Thistechnique may be desirable, for example, in order to begin a moreincremental or step-wise process of building common relationships withinthe master.

In some embodiments, the hierarchy management system 130 also maysupport map rationalization. A map rationalization may allowusers/applications to rationalize map sets, that is, to move mappingsfrom the application level to the master level for sharing. In someimplementations, map sets may be individually rationalizable, like nodesand properties, while in other implementations only all-or-nothingrationalization may be supported for map sets, with include/excludeoptions as in relationship/hierarchy rationalization.

Additionally, as part of the rationalization process, the hierarchymanagement system 130 may support property definition rationalization.That is, the rationalization tools of the property definitionrationalization may allow administrative users to combine two propertiesinto a single property.

In some embodiments, the hierarchy management system 130 also maysupport chunk rationalization. Chunk rationalization may include theability to replace application level objects in a chunk chain withmaster level objects. Processes for replacing an application-level chunkobject with a master chunk object may include comparing the applicationnode types in the definition of the application chunk object to themaster node types in the definition of the master chunk object. A nodetype mapping feature may be used to facilitate such comparisons. In somecases, only objects with valid application node type to master node typemappings may be used during a chunk rationalization process. However,even when valid node type mappings are considered, replacing anapplication chunk object with a master object may potentially bedisruptive to the subscriber applications 120 in some cases. Thus, insome embodiments, one or more chunk rationalization tools supported bythe hierarchy management system 130 may allow the user/applicationinitiating a potential chuck rationalization to see and review datadifferences due to the replacement of the old application chunk objectwith the new master object, before committing to the chunkrationalization.

In various examples, two different styles of chunk rationalization maybe supported: a promotion chunk rationalization and a replacement chunkrationalization. In promotion chunk rationalization, an applicationobject may be promoted to a master. When promoting an application objectto a master, the hierarchy management system 130 may be configured toautomatically create the master based on the application object, and mayattempt to replace (to the extent possible) application node types withmaster node types, based on the node type mappings. In replacement chunkrationalization, an application chunk may be replaced with an existingmaster. When replacing an application chunk with an existing master, thedifference feature of the rationalization tool may be used to inform theuser/application what will change due to the replacement. Additionally,in embodiments, a notification request may be optionally generated, ormay be required, for view sections that incur any data changes due tothe replacement. Additionally, because of the complexity of replacingchunk chain objects, the hierarchy management system 130 may include theability to lock certain chunk objects, and their associated chains, whendoing chunk rationalization.

Chunk chain rationalization (CCR) also may be supported in someembodiments. Chunk chain rationalization tools of the hierarchymanagement system 130 may support promoting of validations and usergroups up a chunk chain, in order to get more reuse and promotestandardization. In some cases, chunk chain rationalization may beperformed so as not to affect the actual chunk objects themselves. A CCRtool also may include a user interface with a visual designer component,to allow users/applications to view and maintain the placement ofvalidations and user groups on the chunk chain. The same or a similarvisual component may be used to allow users/applications to inspect thechunk objects, their place in the chain, and other dependent objects.

Governance Pools in Hierarchical Systems

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) described herein relate toimplementing governance pools in hierarchical data systems. In someembodiments, an automated governance process may be used to process andexpedite all data and metadata changes within the master data store 135and/or individual system data systems 121-124. As described below, theautomated governance process may determine a number of differentcontextual pools (e.g., an enrichment pool, approval pool, review pool,etc.), output invitations to users of the contextual pools, and managefeedback received from users of the contextual pools. The users of theparticular contextual pools may be determined based on the type ofchange, and/or any data correction/enrichment that needs to occur, andthe appropriate users will be invited to the various processes (e.g.,approval, enrichment, and review) for the requested change. Along withchanges to nodes, relationships, and property values, users will be ableto request changes to metadata, like new properties, new validations,changes to existing workflow, etc. In various embodiments, suchautomated governance process may be invoked in response to changes tonodes, relationships, and property values, as well as requested changesto metadata, like new properties, new validations, changes to existingworkflow, etc.

Referring now to FIG. 7 , a flow diagram is shown illustrating anexample process for generating a plurality of contextual pools inresponse to a change request. In step 710, a receive is received, forexample, by a request object within the hierarchy management system 130or elsewhere within a hardware/software architecture 100. In thisexample, the request may correspond to a request to add/modify/deletedata or metadata (e.g., properties) from the shared data within a masterdata store 135. As discussed above, the master data may correspond toreference data shared by multiple different heterogeneous systems121-124 implemented within an organization's architecture 100. In step720, the request object may identify one or more systems/datahierarchies affected that would be affected by the requested change, andmay retrieve the ownership data associated with each of the requestedsystems/hierarchies and a set of pool generation rules. Steps 730-750,one or more of which may be optional in various embodiments, correspondto the determination/generation of an approval pool, enrichment pool,and review pool, respectively. Each of these pools may be determineddynamically, based on the current set of rules for pool generation, theaffected systems currently linked to the system for which the change wasrequested, and the current owners of the affected/linked systems.Although three separate contextual pools are used in this example, moreor less pools may be generated in other implementations. Additionally,in some embodiments, users included in one or more contextual poolsduring a change request may opt of the current change request processand/or additional processes generated by change requests for sameobjects in future. Finally, in step 760, the request object may initiatethe automated governance process, through which the multiple usersidentified in the various pools may collaborate to review, modify, andapproval the requested change.

As discussed below, after the initiation of the automated governanceprocess, an object model may handle the processing of the interactiverequests by inviting and coordinating communications with the users ineach of the determined contextual pools. In some cases, the object modelmight not enforce any order with respect to the users in a particularcontextual pools; however, responses from all members of a first poolsmust be received before the automated governance process proceeds to thenext pool in the sequence. In this example, the approval pool is anautomatically generated set of users that are required to approve therequested change. This list may correspond to differentowners/administrators on the different linked systems that would beaffected by the requested change. After completing the approval phase,the automated governance process may proceed to the enrichment phase,which is designed to retrieve and/or determine any required informationthat was not provided with the change request, or any incorrectinformation associated with the change request. As an example, in arequest to set up a new general ledger account, the enrichment phase mayinclude one or more users to provide needed international codes, taxcodes, etc. The enrichment process also tracks what process steps stillneed to be completed, evaluates the validity of the contributions fromthe pool users, and determines which users are delaying the overallchange request process. After the enrichment phase, the change requestis complete and valid. Next, the review pool includes users that arerequired to give final approval for the completed and valid changerequest. Finally, following a successful review phase, a committer mayaccess the automated governance system to apply the change.

Unlike systems in which every workflow model must be pre-configured andeach stage and participating group defined up-front, the automatedgovernance process described herein may use an inference-based workflowmodel that uses security and roles to determine which users should beinvited into the governance process at which points. As noted above, thepool approach may allow users to work in parallel and does not requireusers to work on a request in any particular order. When a particularuser opens a request, that user may see only the items for which theyhave access and the issues that they can fix. Additionally, a user maybe able to do some partial work on a request and then throw it back inthe pool for a different user to finish. In the above example, the onlyrequired steps in the request may be the request submission step and thecommit step. The processing through the interactive and collaborativepools in the approval phase, enrichment phase, and review phase mayoccur based on the settings of the view and the correctness of therequest. For example, a change request to add a new cost center into ashared data hierarchy may require an approval, whereas an update to PBCSproperties may only require a review.

Referring now to FIG. 8 , an example state diagram is shown illustratinga state machine for processing change requests according to certainembodiments described herein. The state diagram of FIG. 8 includes asubmit state, an approve state, an enrich state, a review state, acommit state, and a close state. As discussed above, in differentembodiments, the state diagram may have more or less states. Also shownin FIG. 8 are the transitions, represented the process of the requestobject moving between states. As discussed below, each transition may beassociated with a combination of one or more conditions/actions that maycause the request object to transition between states. As shown in FIG.8 , the following illustrative examples corresponds to state transitionactions that may be performed by a user and/or by the system. Promotetransition actions move the request to the next phase. In this example,promotion from the Commit state results in the request being committed.Pushback transition actions change the phase (or state) to either theSubmit or Enrich states in this example. In some cases, the user maydecide which phase to send the request back to. For example, as shown inFIG. 8 , if the request is in the Review or Commit phase, the user mayselect which phase to send the request back to. Withdraw transitionactions correspond to a withdraw of the request by the submitter. Oncethe request is withdrawn, the lifecycle may be complete and the statechanges to the Closed state. In some cases, in order to withdraw arequest the submitter may first have to first pullback a request.Pullback transition actions, in some examples, may be done only by thesubmitter. Pullback actions may be performed in any phase. For example,a submitter can pullback a request to either make a modification or towithdraw a request. Escalate transition actions may change the state ofthe request, while keeping the request in the same phase. Rejecttransition actions correspond to the lifecycle of the request beingcompleted. In some cases, reject transition actions may be implementedto differentiate from pushback, where in reject transitions the requestis sent to closed phase. Commit transition actions correspond to thecommitting of a request by the user. In such cases, the request may goto the closed phase and the request changes may be applied to the targetview.

Referring now to FIG. 9 , an example object model is illustrated thatmay be used to handle the processing of change requests, for example,through the state transition of FIG. 8 , including the various servicesthat may be invoked to support the request lifestyle. As shown in FIG. 9, the end user (e.g., human or programmatic client) may interact withthe request object. In some embodiments, the end user may never interactwith the state machine or phase model. All user actions may be recordedwithin the request. Depending on the action the user takes (e.g.,submit, promote, validate, reviewed, commit, etc.), the request mayfirst record any actions, and then may delegate the orchestration of therequest to state machine by providing the handle to request object. Thatmay allow the state machine and phase implementation to call variousmethods on the request object.

In some embodiments, this may be implemented as a multi-user system, andmay be configured to support many concurrent users working on a requestat the same time, potentially on different items. However the statemachine may work on the request as a whole and run validations at boththe item and request level. As such any create, read, update and/ordelete (CRUD) operations performed on the request may be synchronized.This may ensure consistency of the system. However, the system also mayimplement an optimistic locking mechanism. In some cases, the systemmight not support a provision for the user to claim and lock a request.All users may work on a request at the same time. By ensuring that CRUDoperations on requests are synchronized, the system may allow multipleusers to process the request simultaneously. This may potentially leadto users seeing stale data, which the system may handle, and inform theuser that the state has changed since they last queried.

The object model shown in FIG. 9 is one example design of how the statemachine shown in FIG. 5 may be implemented. The design shown in FIG. 9may implement certain requirements and provide certain advantages. Forexample, the object model of FIG. 9 may be designed to easilyaccommodate the addition of new transitions and conditions, and mayprovide a modular way to handle different behaviors in different states.Additionally, in the object model shown in FIG. 9 , both transitions andconditions may be configurable and may require minimal changes to thecode. Additionally, the request object model may be agnostic of thestate machine and its implementation. The model also may allow for theaddition of new functionality, for example, relating to the statebehavior, in a incremental and non-invasive manner, and also may allowfor the addition of different request types in a seamless manner.

The object model shown in FIG. 9 includes three distinct parts:Requests, RequestStateMachine, and RequestPhaseModel. In this example,the requests may store a pointer to the current phase that the requestis in, and nothing else. The request may have no knowledge about itslifecycle events; however, it may provide the necessary methods for theclients to manage lifecycle events. As noted above, the request is theobject with which clients/users interact. As such, the request interfacemay expose all the necessary lifecycle events, although the request maydelegate lifecycle management to the state machine.

As shown in FIG. 9 , the object model may implement the state machinefor change requests. Lifecycle management of the request may bedelegated to the state machine. The request may be the primary client ofthe state machine, and every time the user performs an action on arequest, the request may delegate the action to the state machine. Insome embodiments, the state machine may perform, for example, thefollowing four functions. First, the state machine may introspect theincoming request and determine if any operations should be performed inthe current phase. This may be done by incoming the appropriatelifecycle methods on the Phase Interface. The proposed phase design maya) provide common functionality across all phases while allowing for theoption to override any phase specific behavior in the inherited classes,and 2) provide functionality to easily add any new phases in the future.Second, the state machine may query the transition map to determine thenext phase based on the action performed by the user. As noted above,the user may be a person or an automated action instantiated by thesystem. Once the next phase is determined, the state machine may callthe appropriate lifecycle methods for that phase. Third, the statemachine may set the phase in the request object. And fourth, the statemachine may return appropriate status back to request to report back tothe user, if required.

In this example, the Request Phase Model portion of the model may beresponsible for handling the various phases of the request. The modelmay provide the flexibility to both provide common functionality sharedby all phases as well as the ability to override and augment behavior inany phase as required. This may also very easily be exposed to handlephases of different request types.

Additionally, the Invitation Management Service in this example may sendout notifications to all participants, based on approval group settingwith a link to the request and the action they have to take. If a userhas previously opted out, they should not be sent a notification. TheInvitation Management Service also may handle auto-renege, so that whena user performs an action, the Invitation Management Service may beinvoked to determine if the invitation can be reneged from otherparticipants. If so, then the user will no longer see the notificationin their queue. Opt-out information may be preserved by the theInvitation Management Service during pushback. Additionally, theInvitation Management Service may update the request for the list ofinvitees. This may ensure that repeated invitations are not sent. Otherthings like opt-outs and auto-renege also may require this information.This information may be maintained per phase as the list of invitees maybe different in different phases. A new data model object may be createdto track all the invites and action taken by participants.

The validation engine may be configured to run both request and requestitem level validations for the phase in questions. In some embodiments,most or all validations of the current and all prior phases may have tobe run during the validation process. The validation engine also mayperform the necessary CRUD to update the request and request itemspecific tables. In general, validations may performed on data that theuser is requesting, for example, nodes and property values. In someembodiments, there may be three distinct categories of validations:user-defined validations, system validations, and phase validations.

User-defined validations are validations defined by the user. Thesevalidations may be functional in nature, or may require adherence to acertain business process. The system may expose an interface for usersto create and manage user-defined validations. These validations maythen be tied to a view, which in turn may be executed when changes arerequested on a view. Validations also may be defined up and down thechunk chain, and the engine may run all the validations as appropriateand report back status to the phase.

System validations might not be defined at any location, but may be runas part of every request to ensure consistency of the system. Someexamples of system validations include validating the uniqueness ofnames, validations to detect foreign key violations, validations todetect loops and cycles in a hierarchy. If the system detects any systemvalidation failures, the request may automatically be sent back to thesubmitter for modification. Until the violations are addressed, thesystem may not allow the user to promote the request to the next phase.

Phase validations may include different validations specific todifferent phases. For example, when a request is submitted, a specificset of submit phase validations may be performed. A severity may beassigned to each validation, and the severity may determine if therequest is promoted to subsequent phase. For example, if a validationfailure is a warning, then a notification may be be sent and the requestmay be promoted to the Approve Phase. Otherwise, the request may not bemoved, and the submitter may be informed of the validation failure(s).In some embodiments, when a request reaches the enrich phase, allvalidations may be executed. Based on that new request, actions may becreated and invites sent to stakeholders based on approval groupsettings. Remedy actions may include, for example, actions such ascreating a new child, moving an existing node, stranded parent, etc.Similarly, the commit phase also may run all the validations, both onentry and just before the request is finally committed to the system.Validation errors may be be flagged in the request, and the users may beinformed based on the approval group settings for this phase. Users mayeither take action on those validations, or may push the request back tothe enrich or submit phase.

After the request is committed, new requests may be spawned off forcertain use cases, such as for membership requests and/or notificationrequests. For example, for a membership request, if the object ismastered, then other views may have subscribed to the changes and theymay be informed via a membership request to either include the changes.In a notification request, the changes done may be propagated to anotherapplication/view, and the stakeholders may be informed of the change.

In some embodiments, when a request is pushed back or when any backwardmovement occurs, any and all approval flags may be cleared out. This mayforce re-approvals as the request moves back through the pools. Newnotifications may be sent out once a request is pushed back.Additionally, in some cases, an instructional request may be transmittedto make sure that the request description is changed. In such cases,this validation may not be cleared, but the person pushing back may beasked if they want to reset the validation.

The Policy Compliance Engine is potentially a separate service, or maybe implemented as part of the validation service. The policy complianceengine/service may be responsible for ensuring compliance to thebusiness process. Policy compliance might not focused on the actualdata, but may verify compliance of policies such as the four-eyesprinciple, a policy to require approval and promotion in each phase, apolicy designating how pushbacks will be handled, etc.

Additionally, validations may be triggered at various points of therequest lifecycle. Depending on the validation, the system may determinewhen a particular validation is fired. The three possible trigger pointsof a validation may be OnSubmit (e.g., by user in the submit phase),OnPromote (e.g., initiated by a user or the system), or OnDemand (e.g.,may be triggered in any phase by an explicit validate action).

Application Materialization in Hierarchical Systems

Reporting systems with data visualization functionalities can provideusers with the capability to convert diverse data into information thatcan be easily visualized and deciphered to exploit the information andlearn more about the business. Visualization components can emphasizehigh-level patterns and trends in large and complex datasets. One way ofpresenting vast amounts of data as comprehendible information is byrepresenting the data in a treemap format. A treemap is a visualrepresentation of a dataset, which is typically hierarchical in nature.

A treemap generally includes a collection of two-dimensional cells ofrectangular shape, each of which represents one or more data entries ofthe dataset. The cells of a treemap have characteristics, such as area,color, and texture, that represent the data. The cell characteristicsmay also be known as graphical attributes. If the dataset is in the formof a table in a database, the rows of the table may be represented bytreemap cells and the columns of the table may represent various datadimensions. A data dimension is a set of related data values such as thevalues in a column of a database table or correlated fields in an XMLfile that are marked with a common tag. The data dimensions may bemapped to different cell characteristics of the treemap visualization.Thus, a viewer of the treemap can gain insight into data by examining agrouping of cells and cell characteristics.

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) are described herein toallow users to interact with their data hierarchies and master datathrough management of materialized, application-centric views. In someembodiments, a single user interface may be provided to allow users toperform both application materialization of the user's applications, andmaster data management. A hierarchy management system 130 and/or othercomponents within an organization's software/hardware architecture 100may generate and render user interfaces through which users may managetheir data hierarchies alongside the master data, usingsimilar/identical views for materialization of application data andmaster data. In other words, users may be able to view/edit theirapplication data hierarchies and/or master data in the same manner andat the same time. The data sharing rules pertaining to the applicationhierarchies and master data may be implemented automatically behind thescenes and transparently to the user. Thus, using the applicationmaterialization techniques describe herein, users may share their datavia incremental rationalization with other users/applications, whilecontinuing to use their application view without any noticeable changes,thereby making rationalization completely transparent to the users. Theuser's application view may remain identical, but the underlying rulesthat maintain and manage the master data/rationalization mayautomatically synchronize through the master.

Referring now to FIG. 10 , a flow diagram is shown illustrating anexample process for materializing (or visualizing) the data dimensionsand/or hierarchies of an application 120, when some or all of theapplication data is mastered. In step 1001, a visualization request isreceived for an application 120 operating within an organizationcomputing infrastructure 100. The request may be received via theapplication 120 itself, or using an administrative tool supported by theapplication 120 and/or the hierarchy management system 130 to allowauthorized users to view and interact with graphical representations oftheir data dimensions and hierarchies. The request also may identify aview level at which the data hierarchies for the application 120 are tobe visualized. In some cases, the view level simply may be the top-levelapplication view, which may correspond to a request to view all of thedata dimensions/hierarchies associated with the requesting application.In other cases, a user may identify a particular data hierarchy,sub-hierarchy, or dimension as the “view” for the materializationrequest.

In step 1002, in response to the visualization request in step 1001, theapplication 120 may determine one or more external data hierarchies ordimensions which store at least a portion of the requested applicationdata. For example, as discussed above, an application 120 may subscribeto particular data dimensions or hierarchies from other externalapplications 120. Additionally, some or all of the requested applicationdata may be mastered, and thus may reside in a master data store 135managed by a hierarchy management system 130. Thus, in step 1003, theapplication 120 may retrieve various application data from one or moresubscribed-to external applications 120 and/or from the master datarepositories of the infrastructure via the hierarchy management system130. Depending on the application visualization view requested in step1001, the application 120 might or might not need to retrieve data fromall subscribed-to external systems and masters. For instance, if thevisualization/materialization request corresponds to a data view of aparticular data dimension maintained solely by the application 120, thenno data retrieval from an external application or master may benecessary, even if the application 120 subscribes to externalapplications and/or master data for other data dimensions.

In step 1004, the application may combine data received from externalapplications 120 and/or master data in step 1003, with additional datamaintained by the application 120 itself. For example, as discussedabove, certain applications 120 may permitted to maintain their ownversion of an application-level data dimension/hierarchy, withnon-shared and non-mastered data nodes, properties, and/orrelationships. In such cases, application 120 may retrieve a portion ofthe requested data to be visualized from subscribed-to externalapplications and/or master data, and then combine the retrieved datawith the non-shared and non-mastered data maintained internally by theapplication. 120. During the combination process in the 1004, thesubscribed-to or master data may be modified based on the preferencesand/or authorization level of the application 120, for example, byadding or modifying the properties or relationships of retrieved datanodes, and/or by appending application-level data nodes to a master datadimension or hierarchy retrieved via the hierarchy management system130. Finally, in step 1005, the combined application data may bedisplayed, at the requested view level, using interactive graphicalinterfaces to represent the requested data dimensions and hierarchies.

Additionally, in some embodiments, the hierarchy management system 130may present the user with data records and relationship structures thatare filtered and shaped similarly to their subscribing application.Additionally, the scope of the changes may be aligned with thesubscribing system's integration methodology. For example, theintegration may support sending entire datasets, individual records, ora set of changes based on a last integration event. The hierarchymanagement system 130 may use the various underlying functionalitiesdescribed herein, such as application views and application adapters, topresent users with a dimension editing experience that is similar oridentical to the external application's dimension editing experience.

Referring briefly to FIGS. 11-13 , three example user interfaces areshown illustrating the application materialization techniques summarizedabove. In FIG. 11 , an entity rationalization user interface is shownthat displays a graphical hierarchical view of a master and threeapplication hierarchies. The user interface in FIG. 11 identifies thereference data overlap between the three application hierarchies, andthe corresponding master data. Users may view listings of properties forthe nodes in each of the three application hierarchies, and as shown inthis example, the properties for an entity rationalized across multipleapplication hierarchies need not be the same in each of the applicationhierarchies. Using the features within the user interface of FIG. 11 ,users may view nodes and properties, rationalize nodes across multipleapplication hierarchies, and/or change existing rationalizations.

In FIG. 12 , a property rationalization user interface is shown thatdisplays a graphical hierarchical view of master data, along with aproperty list and a property definition and usage interface. Using thefeatures within the user interface of FIG. 12 , user may view, create,and modify rationalizations for metadata properties between differentnodes across different applications. In this example, the “alias”property within the “5120000” node of the master has been selected, fromwhich the user may define property rationalizations to threeapplications. Additionally, the user may define the property valuewithin the master using the survivorship expression shown in thisexample.

In FIG. 13 , an application materialization user interface is shown thatdisplays a user's application hierarchy view alongside a correspondingmaster data view. As discussed above, the user interface shown in FIG.13 may allow the user to manage the application hierarchy alongside themaster data, using data sharing rules pertaining to the applicationhierarchies and master data that are implemented automatically behindthe scenes and transparent to the user. In this example, the “Select”menu at the center of the interface may allow the user to customize thehierarchical views based on the type of data overlapping between theapplication and master.

As noted above, the system may use application views and applicationadapters to present users with a dimension editing experience similar tothe external application's dimension editing experience. Additionally,the application materialization techniques described herein may relateto the concepts discussed above by which organizations may implement andbegin using systems without any up-front data rationalization and/orother configuration. Application materialization is another example of a“zero touch launch” feature which may be used without pre-modeling andpre-configuring requirements. In some embodiments, the applicationmaterialization described above may be used as soon as application isregistered and its data has been imported, without needing any furtherconfiguration.

In some embodiments, application adapters may provide the logic toachieve the on-boarding requirements listed above. This may include thebasic information for synchronizing (e.g., importing and exporting), aswell as the node types, properties, and validations that may be requiredfor particular application types. Additionally, an application adaptermay provide the capabilities to perform whatever discovery is availableon the live instance of the application and supply the configurationoptions that drive the application registration process. In certainexamples, a particular PBCS application adapter may perform thefollowing actions as part of registering the PBCS1 application. First,the PBCS application adapter in this example may ask the user forconnection information. After receiving the connector information, thePBCS application adapter may then connect to PBCS1 and determine whichdimensions, UDAs, and other configurable data elements that it is using.The PBCS application adapter may then gather any other configurationinfo available, for example, any constraints, validations, and/orsecurity, that may have been enabled on PBCS1. The PBCS applicationadapter may then prompt the user for any missing configuration answers.Additionally, the PBCS application adapter may prompt the user forcertain Arcadia options as they pertain to PBCS. For example, the usermay be prompted if they want different Node Types for limbs and leafs,and what the names of the Node Types should be. In some cases, defaultsmay be provided to users as options (or may be enforced), correspondingto the best practice defaults. Then, the PBCS application adapter maycreate the appropriate backend data objects (e.g., chunks), may createthe Application View with the proper number of view sections andproperties, and may hook the view sections and properties to the dataobjects. The PBCS application adapter may then add validations and usergroups to the view and view sections. Additionally, in some cases,application adapters may have the ability to seed a new application withexisting dimensions in Arcadia.

As part of the creation process for an application view, an applicationadapter may be hooked to the view and may automatically turn on certainsettings for the view based on the application logic and discoveredconfiguration. Application adapters may contain a list of potentialdimension objects that can relate to the dimensions in their particularapplication. Referring now to FIG. 14 , a block diagram is shownillustrating the relationship between an application adapter and a view,in accordance with certain embodiments. As shown in this example, eachdimension in a registered application may have a 1:1 mapping to a viewSection in the associated view, and the registered application itselfmay have a 1:1 mapping with the view. Each application may have one andonly one “connected” view that supports it. Other views may be setup tosupport an application, but in some embodiments these other view must bedisconnected. That is, the other view may not be able to use thesynching mechanism of the system to feed the application, and only oneview at a time may be able to be officially integrated. This may allowthe system to cleanly govern (e.g., monitor and audit) what has and whathas not been sent to or received from any particular system. However, insome cases, users may be permitted to manually import or export data, inwhich case any data handled in this fashion may not be governed.

In some cases, the application type of a particular application maydetermine which application adapter may be used to manage theregistration and synching processes. The application adapter may use itsbuilt-in logic, plus any specific instance settings about the registeredsystem. For example, the HFM application adapter may define that an HFMapplication may have custom dimensions, but the registered HFM1application may have definitions for the exact custom dimensions in theHFM1 application instance. In other words, the application adapter is aclass that is used to create the registered application for eachapplication instance.

Data Intersection Mastering in Hierarchical Systems

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) are described herein tonatively support data intersections as first-class objects within thearchitecture 100 and its various applications/systems 121-124. Asdiscussed above, multiple applications/systems may include overlappingsets of reference data, which may be rationalized into a master set ofreference data in order to provide a single source of the sharedorganization data. The different types of reference data in a system maydepend on the nature of the organization, but certain examples ofreference data may include customers, employees, documents, products,product lines, stores, geographic regions, computer servers, networkdevices, etc.

In addition to these examples, various embodiments of hierarchymanagement systems 130 may natively support data intersections as partof its core feature set. Data intersections are data nodes defined byvalues in multiple node types. For example, if the following nodes existin their respective Node Types: “Prod001” in Product, “Vend002” inVendor, and “Store16” in Store, an intersection node representing thatproduct supplied by that vendor sold in that store may be“Prod001/Vend002/Store16.” Natively support this intersection mayinclude creating a new node type corresponding to the intersection, forexample, a node type named “Vendor's Product by Store,” in this case. Insuch examples, intersection nodes may have all the same capabilities ofa normal node supported by the hierarchy management systems 130,including properties, relationships, maps, etc. Additionally,intersections may support ranges as part of their definition. Forexample, instead of “Prod001/Vend002/Store16,” a particular intersectionmay be defined with respect to a range in one or more of its componentsegments, such as “Prod001/Vend002/Store10-Store16.”

For example, referring briefly to FIG. 15 , an example portion of a datahierarchy is shown in which a number of intersection data nodes arerepresented. In this example, each of the intersection data nodes1511-1514 corresponds to the intersection of a particular customer datanode, a particular product data node, and a particular store data node.Each intersection data node 1511-1514 thus contains the data for itscomponent parts (e.g., customer, product, and store) including both thedata node values and the properties for those component parts.Additionally, as shown in this example, intersection data nodes mayinclude additional properties and/or relationships defined on theintersection itself (e.g., not properties on the individual componentsof the intersection).

Intersection node types thus may contain multi-dimensional nodes thatrepresent an intersection of nodes from normal node types. For example,Store1 (in the “Store” node type), Product4 (in the “Product” nodetype), and SupplierABC (in the “Supplier” node type) all may exist asnodes in their respective normal node types. However, an additionalintersection node type may be defined (e.g., manually orprogrammatically), named “Supplier Products By Store” that includesnodes representing an intersection of these three normal node types. Anexample node of this intersection node type may be represented as“SupplierABC/Store1/Product4.”

In certain embodiments, intersection nodes may be supported asfirst-class objects, and thus may be handled within the architecture 100as an entity in itself, having all of the same features as other nodetypes. For example, nodes of intersection node types may have propertiesassigned, may be put in a hierarchy, may have attributions on it whichare available (e.g., as live links) at that intersection object, etc.Rules, validations, and governance also may be handled in the same wayfor defined intersection node types as for other normal node types.Additionally, when intersection objects are supported natively asfirst-class objects, they can be versioned over time rationalized aswell.

As an example for illustrative purposes, an organization may create aprice list node type at the intersection of a vendor node type, storenode type, and region node type. In this example, price list objects maybe treated as first-class objects, so that properties could be assignedto the price list object itself (e.g., a price property, a valid/notvalid indicator, a date range property, etc.). Additionally, thisintersection object would inherit the properties of its constituentnodes of normal node types (e.g., the vendor properties, storeproperties, and region properties). The price list nodes in this examplealso could be versioned, put into hierarchies, and have attributed puton them. Further, the price lists in this example, and other dataintersections in other examples, may be rationalized across differentapplications, using the same rationalization techniques describedherein.

Because intersection nodes may be supported as primary/first-classobjects within a computing infrastructure 100, data dimensions and/orhierarchies of intersection nodes in these and other examples may beshared and subscribed-to by separate applications 120, and also may bemastered into a master data store 135 and managed by a hierarchymanagement system 130 as described in the above examples. Thus, datadimensions/hierarchies of intersection nodes may be sharable andreusable across separate applications and systems 120. Additionally,organization-wide policies may master data dimensions/hierarchies ofintersection nodes to provide and/or enforce consistent sets ofintersection nodes at the organization level. Sharing, subscribing, andmastering of intersection nodes may be performed using similartechniques to those discussed above for other data node types. Similarfeatures also may be supported, such as providing differentauthorization permissions for different users and applications 120 withrespect to subscribing to and maintaining individual/customized sets ofintersection node data dimensions/hierarchies. For instance, certainapplications 120 may be required to use a set of mastered intersectiondata nodes for organizational uniformity, while other applications 120may be permitted to maintain separate data dimensions/hierarchies ofintersection data nodes that may be used instead of (or in collaborationwith) the set of mastered intersection data nodes for the same datadimension/hierarchy. In either case, mastered intersection datadimensions/hierarchies may be semantically independent, so thatparticular applications/systems 120 may translate the masteredintersection into the semantics of their particular applications/systems120.

The techniques of mastering intersection data dimensions/hierarchies maysynergies with respect to validation and analysis of individual dataelements. For example, using a single intersection node mastered withinan organization that includes a store element, product element, andcustomer element, an application 120 may quickly be able to analyze theintersection node and perform various calculations based on the datafrom the constituent elements. For example, a transaction taxapplication 120 may use the intersection node to tax the productappropriating using both the product information (from the productelement of the intersection) and the location information (from thestore element of the intersection), etc. Additionally, applications/datasystems 120 within the organization's infrastructure 100 may implementsets of logical rules on mastered intersection nodes and theirconsistent elements to analyze and process the organization's data. Forinstance, processing exception rules may be implemented using themastered intersection data to systematically detect the desiredexception (e.g., when a particular combination of a customer, product,and/or store is detected, apply a special rule), and if the desiredexception is not detected, the processing task may fall through into theprocessing of the general rule. Such solutions allow for groupingtogether and defining precedence on such rules directly within theintersection data nodes themselves, thus provider the user withvisibility into the mappings look-ups and allowing the using to defineprecedence on such rules.

Change Request Visualization in Hierarchical Systems

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) are described hereinrelating to analyses and visualization of change requests withinhierarchical data systems. As discussed above, various different typesof changes may be supported by a hierarchy management system 130 invarious implementations. Changes may include straightforward revisions(e.g., additions, removals, or modifications) of data or metadata forcertain nodes, or more complex examples such as restructuring and/orreorganization of application hierarchies. For instance, a user mayinitiated a request to move a number of child data nodes from one parentnode to another parent node, such as moving N products from one productline to another. As another example, a user may initiate a request tomove a parent node (and all of its subnodes) underneath a differentparent node, such as moving one product line under another product line.As discussed below, these changes may require a restructuring of atleast the application hierarchy containing the affected nodes.Additionally, if the affected data has been shared/rationalized, thenthe other systems 121-124 may be affected. For all affected systems, therestructuring and/or reorganization of application hierarchies has thepotential to create inconsistencies, violate rules, and cause otherpotential data integrity issues. To address these issues, the hierarchymanagement system 130 may provide request visualization features,including underlying request analysis components and requestvisualization user interfaces, to allow users to review the downstreameffects of requested changes before deciding whether or not to modifyand/or commit the changes.

Referring now to FIG. 16 , a flow diagram is shown illustrating anexample process for visualizing, reviewing, and processing data changerequests from an application 120. The graphical interface used forviewing application data changes in this example may be similar oridentical to the view visualization interfaces described above.Additionally, as discussed above, the data change requests reviewed andprocessed in these examples may include entirely siloed application datathat is maintained solely by an application 120, or may include datashared and subscribed to between multiple applications 120, as well asmastered data. Further, although the underlying processing techniquesdescribed herein may be different from siloed data, shared andsubscribed to data, and for master data, in some embodiments theseunderlying processing differences may be entirely transparent to the enduser interacting with the graphical interface.

In step 1601, a data change request may be received from a userassociated with an application 120. The data may include a simple valuechange (e.g., a changing to data node values and/or properties) or amore complex structural change (e.g., reorganizing data hierarchies,changing relationships between data nodes and dimensions, etc.). In step1602, the system may identify any other data affected by the data changerequested in step 1601. For example, if an application 120 is attemptingto make a change to particular shared master data, that shared masterdata may be propagated to one or more additional applications.Additionally, if an application's 120 data dimension is shared withand/or subscribed to by one or more other external applications, thoseexternal applications also may be affected by the data change. In step1603, any affected data dimension/hierarchies from the affectedsystems/applications may be retrieved. In addition to retrieving theaffected data dimension/hierarchies from the other systems, in somecases the data relationships and data integrity rules from those systemalso may be retrieved, in order to determine if the proposed datachange(s) violate any of the rules or affect any of the datarelationships of the other affected systems.

In step 1604, the change request visualization interface may display agraphical change request visualization interface, including all of theaffected internal and external data dimensions/hierarchies. In someembodiments, discussed in more detail in the examples below, the changerequest visualization tool may highlight with graphics any datadiscrepancies or rules violations associated with the proposed change.In step 1605, the user of the change request visualization interface mayreview the changes and commit the changes, thereby initiating thechanges to be performed in step 1606. Alternatively, the user may rejectthe proposed changes after reviewing them in the change requestvisualization interface. In some embodiments, the change requestvisualization interface also may provide the user the option to revisethe proposed data changes, and may update on-the-fly to visualize theaffected data dimensions/hierarchies within the interface.

In some embodiments, request visualization may be performed by a requestvisualization engine within the organization infrastructure 100 (e.g.,within the hierarchy management system 130) configured to servicerequests via a call content within the engine. For example, the callcontext may reference a server cache into which the data change has beencached (using active cache management). A local copy of the modifieddata may be maintained, and during the visualization request, the enginemay apply the request within the call context.

Additionally, as discussed below in more detail, the techniquesdescribed herein for visualizing, reviewing, and committing proposeddata changes may be performed for a single change or for a combinationof data changes. For instance, different users operating withindifferent applications 120 may each propose a change affecting the samemaster data. In such cases, the changes may be incompatible, or even ifcompatible such changes may cause additional unintended consequenceswithin the master data or particular applications 120 that cannot beanticipated by either of the users proposing the separate data changes.Thus, the change request visualization interface may process and displaythe results of affected systems, affected data dimensions/hierarchies,potential broken links or violations of data relationships or dataintegrity rules within the master data or various application-level dataof affected applications 120, etc.

Referring now to FIG. 17 , an example user interface is shown displayingan application view in the context of a particular change request (see1701). As shown in this example, the request visualization tools of thehierarchy management system 130 may overlay the items of the changerequest onto the data in each view section, giving the user a preview ofwhat the data should look like if the request is committed. For thisrequest, the request items are shown in the left pane at 1702, whereeach item is represented by a node. The application views are shown inthe center pane, where the multiple sections are represented by tabs1703. At 1704, buttons are provided through which the user may displaythe sections as either hierarchies or grids, and the properties for theactive node in the current sections are displayed in the property pane1705 on the right side of the user interface. Finally, in theapplication view pane, the request items are overlaid onto the currentlydisplayed view data (see 1706).

Thus, referring to the example request visualization shown in FIG. 17 ,whenever a different node is highlighted in the application view of thecenter pane, the properties for that node are displayed in the rightpane on the right. The node hierarchy and the node properties on theright may be changed by the user in this view, and whenever any changesare made, the listing of changes 1702 is updated. Additionally, theproperty changes are highlighted in the property pane 1705, and the nodechanges are highlighted in the application view pane 1706. Further, theunderlying analysis of the requested change may perform validation andcompliance checks on all affected systems, nodes, and properties. Inthis example, the system has detected an error associated with therequested change to node 512000. The error may indicate, for example, adata inconsistency, a rules violation, or other system data error.

Referring now to FIG. 18 , another example user interface is showndisplaying an application view in the context of a change request. Inthis example, although multiple requests are shown in the requests paneon the left, only a single request 1801 has been selected. Thus, thechanges reflected in the application view center pane 1802 and theproperty pane 1803 on the right, are only those changes associated withthe request 1801, and represent the potential future state of the activeview if request 1801 were to be committed. However, in other examples,the user may select multiple requests from the requests pane at the sametime, which will initiate an underlying process to analyze the effectsof the combination of requests selected, and will display in the userinterface the potential future state of the active view if thecombination of requests were to be committed. Thus, users may evaluateindividual change requests and/or combinations of change requests viathe user interface shown in FIG. 18 .

In this example, when a particular requests 1801 is active, the activerequest may be appended to the view title in pane 1802, and the numberof nodes in the section that are affected by the request may appear inthe section tab. Additionally, as shown in the properties pane 1803, thetwo highlighted properties for node 507000 are updated with request1801. In the center application view pane and right properties pane, sixdifferent operations are visualized, by color and symbol in thisexample, to represent the addition of a new node 1804, the insertion ofan existing node 1805, the deletion of a node 1806, the removal of anode from the current section 1807, a moving of a node 1808, and anupdate to a node/property 1803.

Referring now to FIGS. 19A-21B, several additional user interfaces areshown illustrating techniques for operation visualization. As describedabove for request visualization, new or inserted nodes may be added tothe application view of the request visualization user interface,deleted nodes are indicated as deleted, etc. Node moves and updates, incontrast, may carry additional information that may be disclosed via theuser interfaces, such as information indicating where a node moved fromand/or information indicating a previous value for an updated node. Inthe example shown in FIGS. 19A and 19B, this information may bedisplayed in response to the user clicking on the operation icon. Forinstance, in FIG. 19A, in the property pane or on a property value cell,the user may select (e.g., click) on a property's update operation icon1901. In response, as shown in FIG. 19B, the selected property expandsto show both the new (requested) value 1902 and the old (current) value1903. In some cases, the update icon may work as a toggle, so thatselecting the icon 1901 again may revert to a normal request propertydisplay.

Referring now to FIG. 20 , another user interface is shown illustratinganother technique for operation visualization. In this example,selection of the update icon 2001 in the hierarchy may cause the systemto filter the properties pane 2002 to display only the properties withupdated values for the selected node, and then to display both therequested and current values for each such property.

As another example, referring now to FIGS. 21A and 21B, two more userinterfaces are shown illustrating techniques for operationvisualization. In FIG. 21A, the icon 2101 corresponding to node 0001indicates that this node has been moved in the current change request.If the user selects the move icon 1501, the updated hierarchy display isshown in FIG. 21B indicated the requested and current position for themoved node 0001. FIG. 21B shows the territory and other nodes in betweenthe moved node's requested and current position. This territory may spanthe entire hierarchy in some cases, and all branches within thisterritory may be closed except for the branch containing the oldlocation.

To further illustrate the techniques for request visualization andoperation visualization, the algorithms and functional behaviors foradding a new node to a hierarchy, and for visualization a new node, aredescribed below. When adding a new node, the new node may be child orsibling node to an existing selected node in a hierarchy. In such cases,the system may navigate to the hierarchy, find a parent node, and addthe new node under the parent node in the hierarchy. Additionally, thesystem may select a node type and specify a name and description for thenew node, as well as defining values for any other required and optionalproperties available for the new node in the view section. After makingthe change(s), verification may be performed to confirm that the changesare valid and to correct any issues. At the end of the process, the newnode may be reviewed as a request item in a draft request.

In some embodiments, the following functional steps/algorithm may beperformed by the system (e.g., the hierarchy management system 130) whenadding a new node to a hierarchy. For example, to initiate the processof adding a new node to a hierarchy, the hierarchy management system 130may receive a selection of a view and view section which uses ahierarchy set and has a top node. The hierarchy management system 130may then create a new draft request. The user may then browse thehierarchy to find a parent for the new node, and select a node in thehierarchy which allows child nodes. Via the hierarchy management system130, the user may access a context menu for the node in the hierarchywhich allows child nodes, and an add menu item may then be selected toadd a new node as a child or sibling of the selected node. In somecases, the hierarchy management system 130 may only support the AddChild option for node that allow child nodes. Additionally, in someexamples, an Add Sibling option may be supported by the hierarchymanagement system 130 for all nodes except top nodes. Next, thehierarchy management system 130 may provide a view listing availablechild node types for the selected node. If a child node is being added,then the child node types available for selection may be based on theselected node, wherein if a sibling node is being added, then the childnode types available for selection may be based on the parent of theselected node. The hierarchy management system 130 may then receive theselection of the node type for the new node being added, or mayautomatically select the node type if only one type is available, inwhich cases the hierarchy management system 130 might skip the node typeselection screen and directly transition to the property pane.

Next, the hierarchy management system 130 may provide the propertiesview for the new node being added, based on the view section, in aproperty pane. Within the property pane, editable free form text fieldsmay be shown for all view section properties displayed, and the propertypane may identify the required properties of the new node being added.From user interaction with the property pane, the hierarchy managementsystem 130 may receive a defined name for the new node via a designatedname field in the property pane. In some cases, the hierarchy managementsystem 130 may enforce a maximum (or configured) length for the new nodename. The hierarchy management system 130 also may receive a descriptionfor the new node via a designated description field in the propertypane. In some cases, the description field also may be configured notexceed a maximum or configured field length. Additionally, via theproperty pane, the hierarchy management system 130 may support theaddition of defined values for any other required properties for the newnode, and/or for the addition of defined values for any other optionalproperties for the new node. Additionally, in some embodiments, thehierarchy management system 130 may be configured to identify a propertywhich has been modified for the new node being added, and to show achange indicator for the property immediately after the update has beenapplied.

After a newly-added node is made available in the tree, and then isselected from within the tree, the hierarchy management system 130 maythen provide a view of the new node as a child or sibling of theoriginal selected node in the hierarchy. Additionally, after navigatingaway within the tree, the newly-added node may only be seen under theparent using request visualization. In some embodiments, the hierarchymanagement system 130 may support a validation process, in which theprimary action (node added) performed for the selected node isidentified, and then the property values for the new child node selectedfrom the hierarchy may be viewed. The hierarchy management system 130may identify any validation issues for the property values specified forthe new node, and may make any necessary corrections to the propertyvalues to resolve validation issues. The necessary corrections to theproperty values may be made automatically but the hierarchy managementsystem 130 in some cases, and/or based on user interactions in othercases. Finally, the hierarchy management system 130 may confirm that thevalidation issues have been resolved for the new node being added.

Additionally, in some embodiments, the hierarchy management system 130may support requests for the new node being added. For instance, thehierarchy management system 130 may receive a new request item as adraft request for the new node being added. In some cases, this maycorrespond to the item being expanded in the request pane. In response,the hierarchy management system 130 may identify the view section wherethe node for the expanded request item was added. The hierarchymanagement system 130 also may identify the primary action (e.g., nodeadded) which was performed for the request item in the view section,based on action precedence rules. The hierarchy management system 130may then view the count of node instances which have request items onthe view section tab, where the count is incremented by one for eachnode added, and may save the new request item to the draft request.

After the addition of a new node to a hierarchy, a number of validationsmay be performed in certain embodiments. For example, a validations thatthe node name must be of a particular length (max length or configuredlength), the description must be of a particular length (max length orconfigured length), the name of the new node must be unique within theselected node type, the name of the new node may need to be uniquewithin the current view section, and/or the name of the new node mayneed to be unique under the specified parent. In various cases, thedescription may be required or optional.

Additionally, after the addition of a new child or sibling node to ahierarchy, the users may be provided the capabilities to visualize theaddition of the node. As discussed above in reference to the userinterfaces in FIGS. 17 to 21B, the visualization of changes may enablethe users to identify which parts of the hierarchy are changing and whatmay be affected by the requested changes. In some embodiments,visualization may be available in various user scenarios, including oneor more of the creation of a new draft request, the approval of asubmitted request, the enrichment of a submitted request, the commitmentof a submitted request, the review of a committed request, and/or thereview of a rejected request.

Additionally, in some embodiments, one or more algorithms and/orfunctional steps may be performed by the system (e.g., the hierarchymanagement system 130) to visualize an added node into a hierarchy. Forexample, the hierarchy management system 130 receive an indication thata user has selected a view which uses a hierarchical view section, andan indication of a selection of an in-flight request via the requestpane which includes a request item for adding a node. The hierarchymanagement system 130 may then automatically generate a view for thefirst view section in the view, including request items from theselected request. In some cases, a tab for the view section may have acount of request item instances in the current request. Additionally,the hierarchy management system 130 may automatically expand thehierarchy for the view section to display nodes corresponding to requestitems in the selected request. For example, in such embodiments, thenodes that were newly added in the request may be displayed as childrenof the parent nodes to which they were added in the request. Nodes thatwere newly added in the request also may be marked with various visualindicators in the tree, such as a first visual indicator correspondingto highlighting the row for added node in green, and a second visualindicator corresponding to an Add icon placed in the column on left sideof tree.

The hierarchy management system 130 also may be configured to supportvarious functionality for items selected via the request pane. Forexample, the hierarchy management system 130 may receive an indicationof a user interaction selection a particular request item in the requestpane. In response, the hierarchy management system 130 may provide aview of the request item instances expanded for the selected requestitem. In some cases, the hierarchy management system 130 mayautomatically select the first request item instance in the requestpane, and for instance, may be placed in focus within the tree as aresult of the request item instance being selected in the request pane.Similarly, if and when different request item instances are is selectedwithin the same view section, the hierarchy management system 130 mayplace the node for the selected request item instance in focus withinthe tree. When an added node is selected (based on the view section),the hierarchy management system 130 may be configured to display theproperties of the added/selected node in the property pane. In somecases, within the property pane, the name defined for the node may bedisplayed, along with the description defined for the node. From theproperty pane, properties for the newly-added node may be viewed andselected for modification. In some cases, a change indicator may beshown for a property immediately after the update has been applied orwhen a node is selected in the tree.

Finally, after a different view section is selected, having additionalrequest items that can be visualized, the function steps/algorithms ofthe hierarchy management system 130 may once again automaticallygenerate a view for the newly-selected view section, supporting some orall of the same functionality described above.

Hierarchy Preparation in Hierarchical Systems

Certain techniques (e.g., methods, systems, non-transitorycomputer-readable storage memory storing a plurality of instructionsexecutable by one or more processors, etc.) are described hereinrelating to hierarchy preparation within hierarchical data systems.Hierarchy preparation may refer to the importation of data from datasources (e.g., files) into one or more application hierarchies. Invarious embodiments, hierarchy data may be loaded by pulling informationfrom a desktop or cloud data source. The data may be semi-structured orunstructured in some cases. After loading the information, the hierarchydata may be previewed and/or validated using a number of different rulesand validation checks. Various issues may be identified at the metadatalevel, the individual row/node level, for multiple rows, and/or withinrelationships between nodes. Validation processes may inspect andpre-process the document that has been loaded, and run validation checksto verify that the data set being loaded will conform to the targetapplication view. Additional validation checks may be performed, forexample, to identify any duplicate relationships that may be created,and/or other anomalies or data integrity issues. Any issues identifiedduring the data loading, pre-processing, validating, etc., may beaggregated and presented to the user via a user interface, so that theuser may determine whether or not to proceed with the data importation.

Thus, at a high-level, the hierarchy preparation techniques describedherein may allow users to build intelligence into automated processesfor importing data into a hierarchical data system, in order to ensurereferential integrity of the hierarchy and all hierarchy entities.Further, these techniques provide an awareness of the data beingimported into the hierarchies, and may analyze the data within thecontext of hierarchical master data management.

Referring now to FIG. 22 , a flow diagram is shown illustrating anexample process 2200 of hierarchy preparation in accordance with certainembodiments. In step 2210, one or more components with thesoftware/hardware architecture 100 may load data from importation intoan application hierarchy 121-124. In some embodiments, the system mayinvoke a user interface to allow the user to select a file source type(e.g., desktop file or document cloud file), and then to select one ormore files for importation from the selected source. Variousprogrammatic features may be implemented to allow users to importmultiple files, and/or to set/update property values during importation.

In step 2220, a preview user interface window may be provided to allowthe user to preview the loaded data. In some cases, the user may previewthe file as-is, in which case the source file may be displayed forconfirmation purposes in a read only grid (e.g., spreadsheet). The usermay perform file validation (e.g., separator, header, row, blanks,etc.), and changes may be allowed to the original declaration. Afterpreviewing the source file(s) in step 2220, the user may initiate one ormore save methods. In some cases, the user may declare a new source(e.g., save as CLOB to database, select from a list of sources and/oradd a new source type). The new and old sources may be included to showas part of the data provenance/lineage of the loaded files. Additionallyor alternatively, a save method may be performed as part of a requestfor payload via a file attachment.

In step 2230, one or more hierarchy preparation and/or pruning processesmay be performed on the loaded data. During these processes, variousitem/action validations may be executed, for example, a valid node typein target view section (e.g., leaf, limb) validation, a propertydefinition existence validation in the view section, a samenode/multiple entries in data file validation, a validation to determineif the node already exists in the target view section (e.g., sharednode, alternate hierarchy insert), a parent existence in the target viewsection validation, and/or a same node/multiple parents/parents indifferent view sections validation.

Additionally, a number of grid actions (e.g., processing of spreadsheetdata and/or identification of various classes of issues and suggestedactions) may be supported in this steps. For example, in response to adetermination of an invalid parent, the system may be configured to adda row/node and copy the parent to added node, and to create the validparent by sequencing the parent ahead of original add node action. Inresponse to a determination that a node exists, the system may beconfigured to add a row, create a shared node entry, and prompt the userto select a parent. Otherwise, the system may offer to select node inthe node set. In response to an alternate hierarchy insertion, thesystem may add a column/cell in order to add a relationship to thealternate view section, and then select the valid parent via ellipsis.This may apply to node properties only; if a relationship's propertiesmust be loaded, the system may prompt the user to load a new worksheet.In response to the detection of an invalid entry, the system may deletethe grid row as an invalid member, e.g., required/read only/missingproperties. Finally, in response to a determination that a metadatachange is required, the system may delete the grid column (propertydefinition not available in target view), and may send a new metadatarequest to the administrator.

In step 2240, the data may be posted as a change request to thehierarchy, completing the importation process. In some cases, the usermay request and/or receive data importation statistics corresponding tothe original file (e.g., number of rows, number of columns, number oferrors, etc.) and for the prepared file (e.g., number of nodes, numberof properties, number of relationships, etc.). The posting of a changerequest in step 2240 may correspond to the step of receiving changerequests, which was discussed above in relation to certain requestvisualization techniques. For instance, the change request posted instep 2240 may be posted to the requests pane for certain authorizedusers of one or more affected application hierarchies.

Hardware and Software Computing Environment

FIG. 23 depicts a simplified diagram of a distributed system 2300 forimplementing an embodiment. In the illustrated embodiment, thedistributed system 2300 includes one or more client computing devices2302, 2304, 2306, and 2308, which are configured to execute and operatea client application such as a web browser, proprietary client (e.g.,Oracle Forms), or the like over one or more network(s) 2310. The server2312 may be communicatively coupled with the remote client computingdevices 2302, 2304, 2306, and 2308 via network 2310.

In various embodiments, the server 2312 may be adapted to run one ormore services or software applications such as services and applicationsthat provide message delivery services. In certain embodiments, theserver 2312 may also provide other services or software applications caninclude non-virtual and virtual environments. In some embodiments, theseservices may be offered as web-based or cloud services or under aSoftware as a Service (SaaS) model to the users of the client computingdevices 2302, 2304, 2306, and/or 2308. Users operating the clientcomputing devices 2302, 2304, 2306, and/or 2308 may in turn utilize oneor more client applications to interact with the server 2312 to utilizethe services provided by these components.

In the configuration depicted in FIG. 23 , the software components 2318,2320 and 2322 of system 2300 are shown as being implemented on theserver 2312. In other embodiments, one or more of the components of thesystem 2300 and/or the services provided by these components may also beimplemented by one or more of the client computing devices 2302, 2304,2306, and/or 2308. Users operating the client computing devices may thenutilize one or more client applications to use the services provided bythese components. These components may be implemented in hardware,firmware, software, or combinations thereof. It should be appreciatedthat various different system configurations are possible, which may bedifferent from distributed system 2300. The embodiment shown in FIG. 23is thus one example of a distributed system for implementing anembodiment system and is not intended to be limiting.

The client computing devices 2302, 2304, 2306, and/or 2308 may includevarious types of computing systems. For example, client device mayinclude portable handheld devices (e.g., an iPhone®, cellular telephone,an iPad®, computing tablet, a personal digital assistant (PDA)) orwearable devices (e.g., a Google Glass® head mounted display), runningsoftware such as Microsoft Windows Mobile®, and/or a variety of mobileoperating systems such as iOS, Windows Phone, Android, BlackBerry 10,Palm OS, and the like. The devices may support various applications suchas various Internet-related apps, e-mail, short message service (SMS)applications, and may use various other communication protocols. Theclient computing devices may also include general purpose personalcomputers including, by way of example, personal computers and/or laptopcomputers running various versions of Microsoft Windows®, AppleMacintosh®, and/or Linux operating systems. The client computing devicescan be workstation computers running any of a variety ofcommercially-available UNIX® or UNIX-like operating systems, includingwithout limitation the variety of GNU/Linux operating systems, such asfor example, Google Chrome OS. Client computing devices may also includeelectronic devices such as a thin-client computer, an Internet-enabledgaming system (e.g., a Microsoft Xbox gaming console with or without aKinect® gesture input device), and/or a personal messaging device,capable of communicating over the network(s) 2310.

Although distributed system 2300 in FIG. 23 is shown with four clientcomputing devices, any number of client computing devices may besupported. Other devices, such as devices with sensors, etc., mayinteract with the server 2312.

The network(s) 2310 in the distributed system 2300 may be any type ofnetwork familiar to those skilled in the art that can support datacommunications using any of a variety of available protocols, includingwithout limitation TCP/IP (transmission control protocol/Internetprotocol), SNA (systems network architecture), IPX (Internet packetexchange), AppleTalk, and the like. Merely by way of example, thenetwork(s) 2310 can be a local area network (LAN), networks based onEthernet, Token-Ring, a wide-area network, the Internet, a virtualnetwork, a virtual private network (VPN), an intranet, an extranet, apublic switched telephone network (PSTN), an infra-red network, awireless network (e.g., a network operating under any of the Instituteof Electrical and Electronics (IEEE) 802.11 suite of protocols,Bluetooth®, and/or any other wireless protocol), and/or any combinationof these and/or other networks.

The server 2312 may be composed of one or more general purposecomputers, specialized server computers (including, by way of example,PC (personal computer) servers, UNIX® servers, mid-range servers,mainframe computers, rack-mounted servers, etc.), server farms, serverclusters, or any other appropriate arrangement and/or combination. Theserver 2312 can include one or more virtual machines running virtualoperating systems, or other computing architectures involvingvirtualization. One or more flexible pools of logical storage devicescan be virtualized to maintain virtual storage devices for the server.Virtual networks can be controlled by the server 2312 using softwaredefined networking. In various embodiments, the server 2312 may beadapted to run one or more services or software applications describedin the foregoing disclosure. For example, the server 2312 may correspondto a server for performing processing as described above according to anembodiment of the present disclosure.

The server 2312 may run an operating system including any of thosediscussed above, as well as any commercially available server operatingsystem. Server 2312 may also run any of a variety of additional serverapplications and/or mid-tier applications, including HTTP (hypertexttransport protocol) servers, FTP (file transfer protocol) servers, CGI(common gateway interface) servers, JAVA® servers, database servers, andthe like. Exemplary database servers include without limitation thosecommercially available from Oracle, Microsoft, Sybase, IBM(International Business Machines), and the like.

In some implementations, the server 2312 may include one or moreapplications to analyze and consolidate data feeds and/or event updatesreceived from users of the client computing devices 2302, 2304, 2306,and 2308. As an example, data feeds and/or event updates may include,but are not limited to, Twitter® feeds, Facebook® updates or real-timeupdates received from one or more third party information sources andcontinuous data streams, which may include real-time events related tosensor data applications, financial tickers, network performancemeasuring tools (e.g., network monitoring and traffic managementapplications), clickstream analysis tools, automobile trafficmonitoring, and the like. The server 2312 may also include one or moreapplications to display the data feeds and/or real-time events via oneor more display devices of the client computing devices 2302, 2304,2306, and 2308.

The distributed system 2300 may also include one or more databases 2314and 2316. These databases may provide a mechanism for storinginformation such as inventory information, and other information used bythe example embodiments. Databases 2314 and 2316 may reside in a varietyof locations. By way of example, one or more of databases 2314 and 2316may reside on a non-transitory storage medium local to (and/or residentin) the server 2312. Alternatively, the databases 2314 and 2316 may beremote from the server 2312 and in communication with the server 2312via a network-based or dedicated connection. In one set of embodiments,the databases 2314 and 2316 may reside in a storage-area network (SAN).Similarly, any necessary files for performing the functions attributedto the server 2312 may be stored locally on the server 2312 and/orremotely, as appropriate. In one set of embodiments, the databases 2314and 2316 may include relational databases, such as databases provided byOracle, that are adapted to store, update, and retrieve data in responseto SQL-formatted commands.

In some embodiments, the message delivery services described above maybe offered as services via a cloud environment. FIG. 24 is a simplifiedblock diagram of one or more components of a system environment 2400 inwhich services may be offered as cloud services, in accordance with anembodiment. In the illustrated embodiment in FIG. 24 , systemenvironment 2400 includes one or more client computing devices 2404,2406, and 2408 that may be used by users to interact with a cloudinfrastructure system 2402 that provides cloud services, includingservices for dynamically modifying documents (e.g., webpages) responsiveto usage patterns. Cloud infrastructure system 2402 may comprise one ormore computers and/or servers that may include those described above forserver 2312.

It should be appreciated that cloud infrastructure system 2402 depictedin FIG. 24 may have other components than those depicted. Further, theembodiment shown in FIG. 24 is only one example of a cloudinfrastructure system that may incorporate some of the exampleembodiments. In some other embodiments, cloud infrastructure system 2402may have more or fewer components than shown in the figure, may combinetwo or more components, or may have a different configuration orarrangement of components.

Client computing devices 2404, 2406, and 2408 may be devices similar tothose described above for 2302, 2304, 2306, and 2308. Client computingdevices 2404, 2406, and 2408 may be configured to operate a clientapplication such as a web browser, a proprietary client application(e.g., Oracle Forms), or some other application, which may be used by auser of the client computing device to interact with cloudinfrastructure system 2402 to use services provided by cloudinfrastructure system 2402. Although exemplary system environment 2400is shown with three client computing devices, any number of clientcomputing devices may be supported. Other devices such as devices withsensors, etc. may interact with cloud infrastructure system 2402.

Network(s) 2410 may facilitate communications and exchange of databetween clients 2404, 2406, and 2408 and cloud infrastructure system2402. Each network may be any type of network familiar to those skilledin the art that can support data communications using any of a varietyof commercially-available protocols, including those described above fornetwork(s) 2310.

In certain embodiments, services provided by cloud infrastructure system2402 may include a host of services that are made available to users ofthe cloud infrastructure system on demand. In addition to servicesrelated to account management, various other services may also beoffered including without limitation online data storage and backupsolutions, Web-based e-mail services, hosted office suites and documentcollaboration services, database processing, managed technical supportservices, and the like. Services provided by the cloud infrastructuresystem can dynamically scale to meet the needs of its users.

In certain embodiments, a specific instantiation of a service providedby cloud infrastructure system 2402 may be referred to herein as a“service instance.” In general, any service made available to a user viaa communication network, such as the Internet, from a cloud serviceprovider's system is referred to as a “cloud service.” Typically, in apublic cloud environment, servers and systems that make up the cloudservice provider's system are different from the customer's ownon-premises servers and systems. For example, a cloud service provider'ssystem may host an application, and a user may, via a communicationnetwork such as the Internet, on demand, order and use the application.

In some examples, a service in a computer network cloud infrastructuremay include protected computer network access to storage, a hosteddatabase, a hosted web server, a software application, or other serviceprovided by a cloud vendor to a user, or as otherwise known in the art.For example, a service can include password-protected access to remotestorage on the cloud through the Internet. As another example, a servicecan include a web service-based hosted relational database and ascript-language middleware engine for private use by a networkeddeveloper. As another example, a service can include access to an emailsoftware application hosted on a cloud vendor's web site.

In certain embodiments, cloud infrastructure system 2402 may include asuite of applications, middleware, and database service offerings thatare delivered to a customer in a self-service, subscription-based,elastically scalable, reliable, highly available, and secure manner. Anexample of such a cloud infrastructure system is the Oracle Public Cloudprovided by the present assignee.

Cloud infrastructure system 2402 may also provide “big data” elatedcomputation and analysis services. The term “big data” is generally usedto refer to extremely large data sets that can be stored and manipulatedby analysts and researchers to visualize large amounts of data, detecttrends, and/or otherwise interact with the data. This big data andrelated applications can be hosted and/or manipulated by aninfrastructure system on many levels and at different scales. Tens,hundreds, or thousands of processors linked in parallel can act uponsuch data in order to present it or simulate external forces on the dataor what it represents. These data sets can involve structured data, suchas that organized in a database or otherwise according to a structuredmodel, and/or unstructured data (e.g., emails, images, data blobs(binary large objects), web pages, complex event processing). Byleveraging an ability of an embodiment to relatively quickly focus more(or fewer) computing resources upon an objective, the cloudinfrastructure system may be better available to carry out tasks onlarge data sets based on demand from a business, government agency,research organization, private individual, group of like-mindedindividuals or organizations, or other entity.

In various embodiments, cloud infrastructure system 2402 may be adaptedto automatically provision, manage and track a customer's subscriptionto services offered by cloud infrastructure system 2402. Cloudinfrastructure system 2402 may provide the cloud services via differentdeployment models. For example, services may be provided under a publiccloud model in which cloud infrastructure system 2402 is owned by anorganization selling cloud services (e.g., owned by Oracle Corporation)and the services are made available to the general public or differentindustry enterprises. As another example, services may be provided undera private cloud model in which cloud infrastructure system 2402 isoperated solely for a single organization and may provide services forone or more entities within the organization. The cloud services mayalso be provided under a community cloud model in which cloudinfrastructure system 2402 and the services provided by cloudinfrastructure system 2402 are shared by several organizations in arelated community. The cloud services may also be provided under ahybrid cloud model, which is a combination of two or more differentmodels.

In some embodiments, the services provided by cloud infrastructuresystem 2402 may include one or more services provided under Software asa Service (SaaS) category, Platform as a Service (PaaS) category,Infrastructure as a Service (IaaS) category, or other categories ofservices including hybrid services. A customer, via a subscriptionorder, may order one or more services provided by cloud infrastructuresystem 2402. Cloud infrastructure system 2402 then performs processingto provide the services in the customer's subscription order.

In some embodiments, the services provided by cloud infrastructuresystem 2402 may include, without limitation, application services,platform services and infrastructure services. In some examples,application services may be provided by the cloud infrastructure systemvia a SaaS platform. The SaaS platform may be configured to providecloud services that fall under the SaaS category. For example, the SaaSplatform may provide capabilities to build and deliver a suite ofon-demand applications on an integrated development and deploymentplatform. The SaaS platform may manage and control the underlyingsoftware and infrastructure for providing the SaaS services. Byutilizing the services provided by the SaaS platform, customers canutilize applications executing on the cloud infrastructure system.Customers can acquire the application services without the need forcustomers to purchase separate licenses and support. Various differentSaaS services may be provided. Examples include, without limitation,services that provide solutions for sales performance management,enterprise integration, and business flexibility for largeorganizations.

In some embodiments, platform services may be provided by cloudinfrastructure system 2402 via a PaaS platform. The PaaS platform may beconfigured to provide cloud services that fall under the PaaS category.Examples of platform services may include without limitation servicesthat enable organizations (such as Oracle) to consolidate existingapplications on a shared, common architecture, as well as the ability tobuild new applications that leverage the shared services provided by theplatform. The PaaS platform may manage and control the underlyingsoftware and infrastructure for providing the PaaS services. Customerscan acquire the PaaS services provided by cloud infrastructure system2402 without the need for customers to purchase separate licenses andsupport. Examples of platform services include, without limitation,Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS),and others.

By utilizing the services provided by the PaaS platform, customers canemploy programming languages and tools supported by the cloudinfrastructure system and also control the deployed services. In someembodiments, platform services provided by the cloud infrastructuresystem may include database cloud services, middleware cloud services(e.g., Oracle Fusion Middleware services), and Java cloud services. Inone embodiment, database cloud services may support shared servicedeployment models that enable organizations to pool database resourcesand offer customers a Database as a Service in the form of a databasecloud. Middleware cloud services may provide a platform for customers todevelop and deploy various business applications, and Java cloudservices may provide a platform for customers to deploy Javaapplications, in the cloud infrastructure system.

Various different infrastructure services may be provided by an IaaSplatform in the cloud infrastructure system. The infrastructure servicesfacilitate the management and control of the underlying computingresources, such as storage, networks, and other fundamental computingresources for customers utilizing services provided by the SaaS platformand the PaaS platform.

In certain embodiments, cloud infrastructure system 2402 may alsoinclude infrastructure resources 2430 for providing the resources usedto provide various services to customers of the cloud infrastructuresystem. In one embodiment, infrastructure resources 2430 may includepre-integrated and optimized combinations of hardware, such as servers,storage, and networking resources to execute the services provided bythe PaaS platform and the SaaS platform, and other resources.

In some embodiments, resources in cloud infrastructure system 2402 maybe shared by multiple users and dynamically re-allocated per demand.Additionally, resources may be allocated to users in different timezones. For example, cloud infrastructure system 2402 may enable a firstset of users in a first time zone to utilize resources of the cloudinfrastructure system for a specified number of hours and then enablethe re-allocation of the same resources to another set of users locatedin a different time zone, thereby maximizing the utilization ofresources.

In certain embodiments, a number of internal shared services 2432 may beprovided that are shared by different components or modules of cloudinfrastructure system 2402 to enable provision of services by cloudinfrastructure system 2402. These internal shared services may include,without limitation, a security and identity service, an integrationservice, an enterprise repository service, an enterprise managerservice, a virus scanning and white list service, a high availability,backup and recovery service, service for enabling cloud support, anemail service, a notification service, a file transfer service, and thelike.

In certain embodiments, cloud infrastructure system 2402 may providecomprehensive management of cloud services (e.g., SaaS, PaaS, and IaaSservices) in the cloud infrastructure system. In one embodiment, cloudmanagement functionality may include capabilities for provisioning,managing and tracking a customer's subscription received by cloudinfrastructure system 2402, and the like.

In one embodiment, as depicted in FIG. 24 , cloud managementfunctionality may be provided by one or more modules, such as an ordermanagement module 2420, an order orchestration module 2422, an orderprovisioning module 2424, an order management and monitoring module2426, and an identity management module 2428. These modules may includeor be provided using one or more computers and/or servers, which may begeneral purpose computers, specialized server computers, server farms,server clusters, or any other appropriate arrangement and/orcombination.

In an exemplary operation, at 2434, a customer using a client device,such as client device 2404, 2406 or 2408, may interact with cloudinfrastructure system 2402 by requesting one or more services providedby cloud infrastructure system 2402 and placing an order for asubscription for one or more services offered by cloud infrastructuresystem 2402. In certain embodiments, the customer may access a cloudUser Interface (UI) such as cloud UI 2412, cloud UI 2414 and/or cloud UI2416 and place a subscription order via these UIs. The order informationreceived by cloud infrastructure system 2402 in response to the customerplacing an order may include information identifying the customer andone or more services offered by the cloud infrastructure system 2402that the customer intends to subscribe to.

At 2436, the order information received from the customer may be storedin an order database 2418. If this is a new order, a new record may becreated for the order. In one embodiment, order database 2418 can be oneof several databases operated by cloud infrastructure system 2418 andoperated in conjunction with other system elements.

At 2418, the order information may be forwarded to an order managementmodule 2420 that may be configured to perform billing and accountingfunctions related to the order, such as verifying the order, and uponverification, booking the order.

At 2440, information regarding the order may be communicated to an orderorchestration module 2422 that is configured to orchestrate theprovisioning of services and resources for the order placed by thecustomer. In some instances, order orchestration module 2422 may use theservices of order provisioning module 2424 for the provisioning. Incertain embodiments, order orchestration module 2422 enables themanagement of business processes associated with each order and appliesbusiness logic to determine whether an order should proceed toprovisioning.

As shown in the embodiment depicted in FIG. 24 , at 2442, upon receivingan order for a new subscription, order orchestration module 2422 sends arequest to order provisioning module 2424 to allocate resources andconfigure resources needed to fulfill the subscription order. Orderprovisioning module 2424 enables the allocation of resources for theservices ordered by the customer. Order provisioning module 2424provides a level of abstraction between the cloud services provided bycloud infrastructure system 2400 and the physical implementation layerthat is used to provision the resources for providing the requestedservices. This enables order orchestration module 2424 to be isolatedfrom implementation details, such as whether or not services andresources are actually provisioned on the fly or pre-provisioned andonly allocated/assigned upon request.

At 2444, once the services and resources are provisioned, a notificationmay be sent to the subscribing customers indicating that the requestedservice is now ready for use. In some instance, information (e.g. alink) may be sent to the customer that enables the customer to startusing the requested services.

At 2446, a customer's subscription order may be managed and tracked byan order management and monitoring module 2426. In some instances, ordermanagement and monitoring module 2426 may be configured to collect usagestatistics regarding a customer use of subscribed services. For example,statistics may be collected for the amount of storage used, the amountdata transferred, the number of users, and the amount of system up timeand system down time, and the like.

In certain embodiments, cloud infrastructure system 2400 may include anidentity management module 2428 that is configured to provide identityservices, such as access management and authorization services in cloudinfrastructure system 2400. In some embodiments, identity managementmodule 2428 may control information about customers who wish to utilizethe services provided by cloud infrastructure system 2402. Suchinformation can include information that authenticates the identities ofsuch customers and information that describes which actions thosecustomers are authorized to perform relative to various system resources(e.g., files, directories, applications, communication ports, memorysegments, etc.) Identity management module 2428 may also include themanagement of descriptive information about each customer and about howand by whom that descriptive information can be accessed and modified.

FIG. 25 illustrates an exemplary computer system that may be used toimplement certain elements, according to some exemplary embodiments. Insome embodiments, computer system 2500 may be used to implement any ofthe various servers and computer systems described above. As shown inFIG. 25 , computer system 2500 includes various subsystems including aprocessing subsystem 2504 that communicates with a number of peripheralsubsystems via a bus subsystem 2502. These peripheral subsystems mayinclude a processing acceleration unit 2506, an I/O subsystem 2508, astorage subsystem 2518 and a communications subsystem 2524. Storagesubsystem 2518 may include tangible computer-readable storage media 2522and a system memory 2510.

Bus subsystem 2502 provides a mechanism for letting the variouscomponents and subsystems of computer system 2500 communicate with eachother as intended. Although bus subsystem 2502 is shown schematically asa single bus, alternative embodiments of the bus subsystem may utilizemultiple buses. Bus subsystem 2502 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. Forexample, such architectures may include an Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnect (PCI) bus, which can beimplemented as a Mezzanine bus manufactured to the IEEE P13176.1standard, and the like.

Processing subsystem 2504 controls the operation of computer system 2500and may comprise one or more processing units 2532, 2534, etc. Aprocessing unit may include be one or more processors, including singlecore or multicore processors, one or more cores of processors, orcombinations thereof. In some embodiments, processing subsystem 2504 caninclude one or more special purpose co-processors such as graphicsprocessors, digital signal processors (DSPs), or the like. In someembodiments, some or all of the processing units of processing subsystem2504 can be implemented using customized circuits, such as applicationspecific integrated circuits (ASICs), or field programmable gate arrays(FPGAs).

In some embodiments, the processing units in processing subsystem 2504can execute instructions stored in system memory 2510 or on computerreadable storage media 2522. In various embodiments, the processingunits can execute a variety of programs or code instructions and canmaintain multiple concurrently executing programs or processes. At anygiven time, some or all of the program code to be executed can beresident in system memory 2510 and/or on computer-readable storage media2510 including potentially on one or more storage devices. Throughsuitable programming, processing subsystem 2504 can provide variousfunctionalities described above for dynamically modifying documents(e.g., webpages) responsive to usage patterns.

In certain embodiments, a processing acceleration unit 2506 may beprovided for performing customized processing or for off-loading some ofthe processing performed by processing subsystem 2504 so as toaccelerate the overall processing performed by computer system 2500.

I/O subsystem 2508 may include devices and mechanisms for inputtinginformation to computer system 2500 and/or for outputting informationfrom or via computer system 2500. In general, use of the term “inputdevice” is intended to include all possible types of devices andmechanisms for inputting information to computer system 2500. Userinterface input devices may include, for example, a keyboard, pointingdevices such as a mouse or trackball, a touchpad or touch screenincorporated into a display, a scroll wheel, a click wheel, a dial, abutton, a switch, a keypad, audio input devices with voice commandrecognition systems, microphones, and other types of input devices. Userinterface input devices may also include motion sensing and/or gesturerecognition devices such as the Microsoft Kinect® motion sensor thatenables users to control and interact with an input device, theMicrosoft Xbox® 360 game controller, devices that provide an interfacefor receiving input using gestures and spoken commands. User interfaceinput devices may also include eye gesture recognition devices such asthe Google Glass® blink detector that detects eye activity (e.g.,“blinking” while taking pictures and/or making a menu selection) fromusers and transforms the eye gestures as input into an input device(e.g., Google Glass®). Additionally, user interface input devices mayinclude voice recognition sensing devices that enable users to interactwith voice recognition systems (e.g., Siri® navigator), through voicecommands.

Other examples of user interface input devices include, withoutlimitation, three dimensional (3D) mice, joysticks or pointing sticks,gamepads and graphic tablets, and audio/visual devices such as speakers,digital cameras, digital camcorders, portable media players, webcams,image scanners, fingerprint scanners, barcode reader 3D scanners, 3Dprinters, laser rangefinders, and eye gaze tracking devices.Additionally, user interface input devices may include, for example,medical imaging input devices such as computed tomography, magneticresonance imaging, position emission tomography, medical ultrasonographydevices. User interface input devices may also include, for example,audio input devices such as MIDI keyboards, digital musical instrumentsand the like.

User interface output devices may include a display subsystem, indicatorlights, or non-visual displays such as audio output devices, etc. Thedisplay subsystem may be a cathode ray tube (CRT), a flat-panel device,such as that using a liquid crystal display (LCD) or plasma display, aprojection device, a touch screen, and the like. In general, use of theterm “output device” is intended to include all possible types ofdevices and mechanisms for outputting information from computer system2500 to a user or other computer. For example, user interface outputdevices may include, without limitation, a variety of display devicesthat visually convey text, graphics and audio/video information such asmonitors, printers, speakers, headphones, automotive navigation systems,plotters, voice output devices, and modems.

Storage subsystem 2518 provides a repository or data store for storinginformation that is used by computer system 2500. Storage subsystem 2518provides a tangible non-transitory computer-readable storage medium forstoring the basic programming and data constructs that provide thefunctionality of some embodiments. Software (programs, code modules,instructions) that when executed by processing subsystem 2504 providethe functionality described above may be stored in storage subsystem2518. The software may be executed by one or more processing units ofprocessing subsystem 2504. Storage subsystem 2518 may also provide arepository for storing data used in accordance with the exampleembodiments.

Storage subsystem 2518 may include one or more non-transitory memorydevices, including volatile and non-volatile memory devices. As shown inFIG. 25 , storage subsystem 2518 includes a system memory 2510 and acomputer-readable storage media 2522. System memory 2510 may include anumber of memories including a volatile main random access memory (RAM)for storage of instructions and data during program execution and anon-volatile read only memory (ROM) or flash memory in which fixedinstructions are stored. In some implementations, a basic input/outputsystem (BIOS), containing the basic routines that help to transferinformation between elements within computer system 2500, such as duringstart-up, may typically be stored in the ROM. The RAM typically containsdata and/or program modules that are presently being operated andexecuted by processing subsystem 2504. In some implementations, systemmemory 2510 may include multiple different types of memory, such asstatic random access memory (SRAM) or dynamic random access memory(DRAM).

By way of example, and not limitation, as depicted in FIG. 25 , systemmemory 2510 may store application programs 2512, which may includeclient applications, Web browsers, mid-tier applications, relationaldatabase management systems (RDBMS), etc., program data 2514, and anoperating system 2516. By way of example, operating system 2516 mayinclude various versions of Microsoft Windows®, Apple Macintosh®, and/orLinux operating systems, a variety of commercially-available UNIX® orUNIX-like operating systems (including without limitation the variety ofGNU/Linux operating systems, the Google Chrome® OS, and the like) and/ormobile operating systems such as iOS, Windows® Phone, Android® OS,BlackBerry® 10 OS, and Palm® OS operating systems.

Computer-readable storage media 2522 may store programming and dataconstructs that provide the functionality of some embodiments. Software(programs, code modules, instructions) that when executed by processingsubsystem 2504 a processor provide the functionality described above maybe stored in storage subsystem 2518. By way of example,computer-readable storage media 2522 may include non-volatile memorysuch as a hard disk drive, a magnetic disk drive, an optical disk drivesuch as a CD ROM, DVD, a Blu-Ray® disk, or other optical media.Computer-readable storage media 2522 may include, but is not limited to,Zip® drives, flash memory cards, universal serial bus (USB) flashdrives, secure digital (SD) cards, DVD disks, digital video tape, andthe like. Computer-readable storage media 2522 may also include,solid-state drives (SSD) based on non-volatile memory such asflash-memory based SSDs, enterprise flash drives, solid state ROM, andthe like, SSDs based on volatile memory such as solid state RAM, dynamicRAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, andhybrid SSDs that use a combination of DRAM and flash memory based SSDs.Computer-readable media 2522 may provide storage of computer-readableinstructions, data structures, program modules, and other data forcomputer system 2500.

In certain embodiments, storage subsystem 2500 may also include acomputer-readable storage media reader 2520 that can further beconnected to computer-readable storage media 2522. Together and,optionally, in combination with system memory 2510, computer-readablestorage media 2522 may comprehensively represent remote, local, fixed,and/or removable storage devices plus storage media for storingcomputer-readable information.

In certain embodiments, computer system 2500 may provide support forexecuting one or more virtual machines. Computer system 2500 may executea program such as a hypervisor for facilitating the configuring andmanaging of the virtual machines. Each virtual machine may be allocatedmemory, compute (e.g., processors, cores), I/O, and networkingresources. Each virtual machine typically runs its own operating system,which may be the same as or different from the operating systemsexecuted by other virtual machines executed by computer system 2500.Accordingly, multiple operating systems may potentially be runconcurrently by computer system 2500. Each virtual machine generallyruns independently of the other virtual machines.

Communications subsystem 2524 provides an interface to other computersystems and networks. Communications subsystem 2524 serves as aninterface for receiving data from and transmitting data to other systemsfrom computer system 2500. For example, communications subsystem 2524may enable computer system 2500 to establish a communication channel toone or more client devices via the Internet for receiving and sendinginformation from and to the client devices.

Communication subsystem 2524 may support both wired and/or wirelesscommunication protocols. For example, in certain embodiments,communications subsystem 2524 may include radio frequency (RF)transceiver components for accessing wireless voice and/or data networks(e.g., using cellular telephone technology, advanced data networktechnology, such as 3G, 4G or EDGE (enhanced data rates for globalevolution), WiFi (IEEE 1702.11 family standards, or other mobilecommunication technologies, or any combination thereof), globalpositioning system (GPS) receiver components, and/or other components.In some embodiments communications subsystem 2524 can provide wirednetwork connectivity (e.g., Ethernet) in addition to or instead of awireless interface.

Communication subsystem 2524 can receive and transmit data in variousforms. For example, in some embodiments, communications subsystem 2524may receive input communication in the form of structured and/orunstructured data feeds 2526, event streams 2518, event updates 2530,and the like. For example, communications subsystem 2524 may beconfigured to receive (or send) data feeds 2526 in real-time from usersof social media networks and/or other communication services such asTwitter® feeds, Facebook® updates, web feeds such as Rich Site Summary(RSS) feeds, and/or real-time updates from one or more third partyinformation sources.

In certain embodiments, communications subsystem 2524 may be configuredto receive data in the form of continuous data streams, which mayinclude event streams 2528 of real-time events and/or event updates2530, that may be continuous or unbounded in nature with no explicitend. Examples of applications that generate continuous data may include,for example, sensor data applications, financial tickers, networkperformance measuring tools (e.g. network monitoring and trafficmanagement applications), clickstream analysis tools, automobile trafficmonitoring, and the like.

Communications subsystem 2524 may also be configured to output thestructured and/or unstructured data feeds 2526, event streams 2528,event updates 2530, and the like to one or more databases that may be incommunication with one or more streaming data source computers coupledto computer system 2500.

Computer system 2500 can be one of various types, including a handheldportable device (e.g., an iPhone® cellular phone, an iPad® computingtablet, a PDA), a wearable device (e.g., a Google Glass® head mounteddisplay), a personal computer, a workstation, a mainframe, a kiosk, aserver rack, or any other data processing system.

Due to the ever-changing nature of computers and networks, thedescription of computer system 2500 depicted in FIG. 25 is intended onlyas a specific example. Many other configurations having more or fewercomponents than the system depicted in FIG. 25 are possible. Based onthe disclosure and teachings provided herein, a person of ordinary skillin the art will appreciate other ways and/or methods to implement thevarious embodiments.

Although specific example embodiments have been described, variousmodifications, alterations, alternative constructions, and equivalentsare also encompassed within the scope of the example embodiments. Theexample embodiments are not restricted to operation within certainspecific data processing environments, but are free to operate within aplurality of data processing environments. Additionally, althoughexample embodiments have been described using a particular series oftransactions and steps, it should be apparent to those skilled in theart that the scope of the example embodiments is not limited to thedescribed series of transactions and steps. Various features and aspectsof the above-described embodiments may be used individually or jointly.

Further, while example embodiments have been described using aparticular combination of hardware and software, it should be recognizedthat other combinations of hardware and software are also within thescope of the example embodiments. The example embodiments may beimplemented only in hardware, or only in software, or using combinationsthereof. The various processes described herein can be implemented onthe same processor or different processors in any combination.Accordingly, where components or modules are described as beingconfigured to perform certain operations, such configuration can beaccomplished, e.g., by designing electronic circuits to perform theoperation, by programming programmable electronic circuits (such asmicroprocessors) to perform the operation, or any combination thereof.Processes can communicate using a variety of techniques including butnot limited to conventional techniques for interprocess communication,and different pairs of processes may use different techniques, or thesame pair of processes may use different techniques at different times.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that additions, subtractions, deletions, and other modificationsand changes may be made thereunto without departing from the broaderspirit and scope as set forth in the claims. Thus, although exampleembodiments have been described, these are not intended to be limiting.Various modifications and equivalents are within the scope of thefollowing claims.

What is claimed is:
 1. A method comprising: receiving, by a computersystem via a first application, a request to update data within one ormore data hierarchies associated with the first application;determining, by the computer system, one or more additional datahierarchies affected by the requested data update, the additional datahierarchies associated with one or more external applications other thanthe first application; retrieving, by the computer system, theadditional data hierarchies associated with the external applicationsother than the first application; determining that the requested dataupdate affects one or more shared master data dimensions within ahierarchical master data store; and rationalizing the hierarchicalmaster data store using the requested data update, wherein rationalizingincludes identifying overlapping reference data shared by two or morehierarchies, extracting the overlapping reference data from the two ormore data hierarchies, and the overlapping reference data is added to amaster data hierarchy.
 2. The method of claim 1, wherein receiving therequest to update the data within the data hierarchies associated withthe first application comprises: receiving a first request, via a firstexecution session of the first application, to update the data withinthe data hierarchies; and receiving a second request, via a secondexecution session of the first application, to update the data withinthe data hierarchies.
 3. The method of claim 2, wherein the data updatesrequested by the first request conflict with the data updates requestedby the second request.
 4. The method of claim 1, wherein determining theadditional data hierarchies affected by the requested data updatecomprises: retrieving, from a hierarchy management server associatedwith the hierarchical master data store, data identifying the externalapplications as subscribers to the one or more shared master datadimensions affected by the requested data update.
 5. The method of claim1, wherein the data hierarchies associated with the first application,and the additional data hierarchies associated with the externalapplications, each have an associated set of data rules and validationsapplicable to their respective data hierarchies.
 6. The method of claim5, further comprising: generating and outputting, via a graphicalinterface, an indication of a violation of a data rule, within a firstexternal data hierarchy associated with a first external application,resulting from the requested data update; receiving, via the graphicalinterface, an instruction to commit the requested data update; andtransmitting a notification indicating a violation of a data rule, to anadministrator account associated with the first external application. 7.The method of claim 1, wherein receiving the request to update the datawithin the data hierarchies associated with the first applicationcomprises: receiving a first request, via the first application, toupdate data within a first data hierarchy maintained by the firstapplication; and receiving a second request, via a second application ofthe one or more external applications, to update data within a seconddata hierarchy maintained by the second application, wherein a shareddata mapping exists between the first data hierarchy and the second datahierarchy.
 8. A system comprising: a processing unit comprising one ormore processors; and memory coupled with and readable by the processingunit and storing therein a set of instructions which, when executed bythe processing unit, causes the system to: receive, by a computer systemvia a first application, a request to update data within one or moredata hierarchies associated with the first application; determine, bythe computer system, one or more additional data hierarchies affected bythe requested data update, the additional data hierarchies associatedwith one or more external applications other than the first application;retrieve, by the computer system, the additional data hierarchiesassociated with the external applications other than the firstapplication; determine that the requested data update affects one ormore shared master data dimensions within a hierarchical master datastore; and rationalize the hierarchical master data store using therequested data update, wherein rationalizing includes identifyingoverlapping reference data shared by two or more hierarchies, extractingthe overlapping reference data from the two or more data hierarchies,and the overlapping reference data is added to a master data hierarchy.9. The system of claim 8, wherein receiving the request to update thedata within the data hierarchies associated with the first applicationcomprises: receiving a first request, via a first execution session ofthe first application, to update the data within the data hierarchies;and receiving a second request, via a second execution session of thefirst application, to update the data within the data hierarchies. 10.The system of claim 9, wherein the data updates requested by the firstrequest conflict with the data updates requested by the second request.11. The system of claim 8, wherein determining the additional datahierarchies affected by the requested data update comprises: determiningthat the requested data update affects one or more shared master datadimensions within a hierarchical master data store; and retrieving, froma hierarchy management server associated with the hierarchical masterdata store, data identifying the external applications as subscribers tothe one or more shared master data dimensions affected by the requesteddata update.
 12. The system of claim 8, wherein the data hierarchiesassociated with the first application, and the additional datahierarchies associated with the external applications, each have anassociated set of data rules and validations applicable to theirrespective data hierarchies.
 13. The system of claim 12, the memorystoring therein additional instructions which, when executed by theprocessing unit, cause the system to: generate and output, via agraphical interface, an indication of a violation of a data rule, withina first external data hierarchy associated with a first externalapplication, resulting from the requested data update; receive, via thegraphical interface, an instruction to commit the requested data update;and transmit a notification indicating a violation of a data rule, to anadministrator account associated with the first external application.14. The system of claim 8, wherein receiving the request to update thedata within the data hierarchies associated with the first applicationcomprises: receiving a first request, via the first application, toupdate data within a first data hierarchy maintained by the firstapplication; and receiving a second request, via a second application ofthe one or more external applications, to update data within a seconddata hierarchy maintained by the second application, wherein a shareddata mapping exists between the first data hierarchy and the second datahierarchy.
 15. A computer-program product tangibly embodied in anon-transitory machine-readable storage medium, including instructionsconfigured to cause one or more data processors to perform actionscomprising: receiving, by a computer system via a first application, arequest to update data within one or more data hierarchies associatedwith the first application; determining, by the computer system, one ormore additional data hierarchies affected by the requested data update,the additional data hierarchies associated with one or more externalapplications other than the first application; retrieving, by thecomputer system, the additional data hierarchies associated with theexternal applications other than the first application; determining thatthe requested data update affects one or more shared master datadimensions within a hierarchical master data store; and rationalizingthe hierarchical master data store using the requested data update,wherein rationalizing includes identifying overlapping reference datashared by two or more hierarchies, extracting the overlapping referencedata from the two or more data hierarchies, and the overlappingreference data is added to a master data hierarchy.
 16. Thecomputer-program product of claim 15, wherein receiving the request toupdate the data within the data hierarchies associated with the firstapplication comprises: receiving a first request, via a first executionsession of the first application, to update the data within the datahierarchies; and receiving a second request, via a second executionsession of the first application, to update the data within the datahierarchies.
 17. The computer-program product of claim 16, wherein thedata updates requested by the first request conflict with the dataupdates requested by the second request.
 18. The computer-programproduct of claim 15, wherein determining the additional data hierarchiesaffected by the requested data update comprises: determining that therequested data update affects one or more shared master data dimensionswithin a hierarchical master data store; and retrieving, from ahierarchy management server associated with the hierarchical master datastore, data identifying the external applications as subscribers to theone or more shared master data dimensions affected by the requested dataupdate.
 19. The computer-program product of claim 15, wherein the datahierarchies associated with the first application, and the additionaldata hierarchies associated with the external applications, each have anassociated set of data rules and validations applicable to theirrespective data hierarchies.
 20. The computer-program product of claim19, including further instructions configured to cause one or more dataprocessors to perform actions comprising: generating and outputting, viaa graphical interface, an indication of a violation of a data rule,within a first external data hierarchy associated with a first externalapplication, resulting from the requested data update; receiving, viathe graphical interface, an instruction to commit the requested dataupdate; and transmitting a notification indicating a violation of a datarule, to an administrator account associated with the first externalapplication.